The Pennsylvania State University The Graduate School College of Engineering

SECURITY AND PRIVACY OF NEW FEATURES ON

SMARTPHONES

A Dissertation in Computer Science and Engineering by Zhi Xu

⃝c 2012 Zhi Xu

Submitted in Partial Fulfillment of the Requirements for the Degree of

Doctor of Philosophy

December 2012 The dissertation of Zhi Xu was reviewed and approved∗ by the following:

Sencun Zhu Associate Professor of Computer Science and Engineering Associate Professor of Information Sciences and Technology Dissertation Advisor Chair of Committee

Guohong Cao Professor of Computer Science and Engineering

Tom La Porta Professor of Computer Science and Engineering

Dennis K.J. Lin Professor of Statistics

Lee Coraor Associate of Computer Science and Engineering Director of Academic Affairs

∗Signatures are on file in the Graduate School. Abstract

Smartphones have become an indispensable part of our daily lives. Thanks to advances in both hardware and software, modern smartphones provide innovative features to third party applications (a.k.a., apps) running on their platforms. Those features, including various onboard sensors and notification services, have been widely applied in third party applications. They allow the developers to build innovative third party applications. Also, they greatly improve the interactive experience for phone users. As these features and their provided services are becoming more and more popular, concerns are raised about whether the features and the services they provide might introduce security vulnerabilities to the smartphone or cause private information leakages of phone users. Because these features are newly introduced and never appear on the previous dumbphones, they have been barely studied from the perspectives of security and privacy in previous literatures. In this dissertation, we present our studies focusing on two types of popular features on smartphones: onboard sensors (and the sensor services they provide) and notification services. For each feature, we elaborate our studies from both the attack side (i.e., exploring attack approaches on phone users utilizing the feature) and the defense side (i.e., proposing designs and solutions to prevent potential feature-based attacks). For the onboard sensors on smartphones, we present a study of inferring a user’s tap inputs on a smartphone with its integrated motion sensors. Specifically, we utilize an installed trojan application to stealthily monitor the device movements and gesture changes of a smartphone using its on-board motion sensors. When the user is interacting with the trojan application, it learns the motion change patterns of tap events. Later, when the user is performing sensitive inputs, such as entering passwords on the touchscreen, the trojan application applies the learnt pattern to infer the occurrences of tap events on the touchscreen as well as the

iii tapped positions on the touchscreen. To manage the onboard sensors and prevent sensor-based attacks, we propose a privacy-aware sensor management framework, called SemaDroid, which extends the existing sensor management framework on Android to provide the compre- hensive and fine-grained access control over onboard sensors. SemaDroid allows the smartphone user to know the sensor usage of every installed application, spec- ify context-aware and quality-of-sensing based access control policies, and enforce the policies in real-time. Further, considering the trade-off between functionali- ties of installed third party applications and privacy of users, SemaDroid provides a privacy bargain feature that allows users to control the disclosure of sensing information while keeping the application running. For the notification service, we show that notification customization may allow an installed trojan application to launch phishing attacks or anonymously post spam notifications. Through our studies on four major smartphone platforms, we show that both Android and BlackBerry OS are vulnerable under the phishing and spam notification attacks. iOS and Windows Phone allow little notification cus- tomization, thus launching the phishing and spam attacks will expose the identity of the trojan application. Our notification service studies point out the important vulnerability of lacking view authentication in the existing view-based smartphone platforms. To prevent the user from being tricked by the phishing notification and to lo- cate the malware application spreading phishing and spam notifications, while still allowing notification customization, we propose a Semi-OS-Controlled notification view design principle and a Notification Logging service. Moreover, to protect applications from fraudulent views, we propose a view authentication framework, named SecureView, which enables the third party applications to add the authen- tication image and text to their sensitive views (e.g. the account login view). The design, implementation, demonstrations, and evaluation of proposed attack and defense approaches are elaborated in the dissertation.

iv Contents

List of Figures xi

List of Tables xiii

Acknowledgments xiv

Chapter 1 Introduction 1 1.1 New Features on Smartphones ...... 1 1.2 Motivation ...... 2 1.3 Contributions ...... 3 1.3.1 Motion Sensor based Logging Attacks ...... 4 1.3.2 Proposed Sensor Management Framework ...... 4 1.3.3 Notification based Phishing and Spam Attacks ...... 5 1.3.4 Preventing Notification based Phishing and Spam Attacks . 6 1.4 Dissertation Outline ...... 7

Chapter 2 Onboard Sensors and Notification Services on Smartphones 8 2.1 Mobile Phone Sensing ...... 9 2.1.1 Types of Onboard Sensors ...... 9 2.1.2 Phone Sensing Applications ...... 10 2.1.3 Existing Sensor Management on Android ...... 11 2.2 Notification Services ...... 12 2.2.1 Notification Categorization ...... 12 2.2.2 Notification Customization ...... 12

v Chapter 3 Inferring User Inputs on Touchscreens Using Motion Sensors 15 3.1 Technical Background ...... 16 3.1.1 User Inputs on Touchscreen ...... 16 3.1.2 Motion Sensors ...... 16 3.1.2.1 Accelerometer Sensor ...... 17 3.1.2.2 Orientation Sensor ...... 18 3.1.2.3 Hardware Specifications ...... 18 3.1.3 Tap-To-Open/Active Interactive Pattern ...... 18 3.2 Related Work ...... 19 3.2.1 Logging Attacks on Smartphones ...... 19 3.2.2 Attacks Relying on Mobile Sensors ...... 20 3.3 Attack Overview ...... 21 3.3.1 Assumptions ...... 21 3.3.2 Attack Goals ...... 21 3.3.3 Attack Workflow ...... 22 3.3.4 Challenges ...... 23 3.4 Tap Event Detection ...... 23 3.4.1 Observed Pattern of Tap Events ...... 24 3.4.2 Proposed Statistic Approach ...... 25 3.4.2.1 Pattern Learning in Training Mode ...... 25 3.4.2.2 Tap Event Detection in Logging Mode ...... 27 3.4.3 Evaluations ...... 28 3.5 Tap Position Inference ...... 30 3.5.1 Gesture Change Analysis ...... 30 3.5.2 Screen Division ...... 32 3.5.3 Proposed Inference Approach ...... 32 3.5.3.1 Classifier Generation in Training Mode ...... 33 3.5.3.2 Inference in Logging Mode ...... 34 3.5.4 Evaluation ...... 35 3.6 Applications on Android ...... 37 3.6.1 Implementation on Android ...... 37 3.6.1.1 Training Mode ...... 37 3.6.1.2 Logging Mode ...... 37 3.6.2 Number Pad Logging Attack ...... 38 3.6.2.1 Attack Overview ...... 38 3.6.2.2 Tap Position Inference ...... 39 3.6.2.3 Evaluations ...... 39 3.6.3 Password Stealing Attack ...... 41 3.6.3.1 Attack Overview ...... 41

vi 3.6.3.2 Tap Position Inference ...... 41 3.6.3.3 Evaluations ...... 43 3.7 Discussion ...... 43 3.7.1 Security Permission Requirements ...... 43 3.7.2 Overhead Analysis ...... 44 3.7.3 Attack on Other Platforms ...... 45 3.7.4 Countermeasures ...... 45

Chapter 4 A Privacy-Aware Sensor Management Framework for Smart- phones 47 4.1 Overview of SemaDroid ...... 47 4.2 Related Works ...... 49 4.2.1 Access Control on Smartphones ...... 49 4.2.2 Sensor Management on Smartphones ...... 50 4.3 Security Model ...... 51 4.3.1 Attack Model ...... 51 4.3.2 Trust Model ...... 52 4.4 SemaDroid Design ...... 52 4.4.1 SemaDroid Framework Design ...... 53 4.4.2 SemaDroid Workflow ...... 54 4.4.2.1 Allowing Sensor Usage Management ...... 55 4.4.2.2 Enforcing Sensor Usage Policies ...... 55 4.5 Usage Policy Design and Enforcement ...... 56 4.5.1 Policy Design ...... 57 4.5.1.1 app-info Section ...... 57 4.5.1.2 policy-info Section ...... 58 4.5.2 Policy Enforcement Context ...... 58 4.5.3 Quality-of-Sensing based Enforcement Rules ...... 60 4.5.4 Policy Enforcement ...... 60 4.6 Privacy Bargain ...... 61 4.6.1 Definition of Privacy Bargain ...... 61 4.6.2 Bargain Procedure using SemaDroid ...... 62 4.6.3 QoSn Adjustment using SemaDroid ...... 63 4.6.3.1 Data Adjustment Rules ...... 63 4.6.3.2 Data Manipulation Rules ...... 63 4.6.3.3 Mock Data Rules ...... 64 4.6.3.4 Rules Refinement ...... 64 4.7 Implementation of SemaDroid ...... 64 4.7.1 Unrestricted Sensors ...... 64

vii 4.7.1.1 Normal Sensor Data Collection ...... 65 4.7.1.2 Policy Enforcement with SemaDroid ...... 67 4.7.2 GPS and Network Location Providers ...... 67 4.7.2.1 Normal Sensor Data Collection ...... 68 4.7.2.2 Policy Enforcement with SemaDroid ...... 68 4.7.3 Camera ...... 69 4.7.3.1 Normal Sensor Data Collection ...... 69 4.7.3.2 Policy Enforcement ...... 69 4.7.4 Microphone ...... 70 4.7.4.1 Normal Sensor Data Collection ...... 70 4.7.4.2 Policy Enforcement ...... 71 4.7.5 Media Recorder ...... 71 4.7.5.1 Normal Sensor Data Collection ...... 71 4.7.5.2 Policy Enforcement ...... 72 4.7.6 Mock Data Generator Service ...... 73 4.8 Application and Demonstration ...... 74 4.8.1 Preventing Private Sensor Data Leakage ...... 74 4.8.1.1 Sensor Usage Review ...... 74 4.8.1.2 Policy Design ...... 74 4.8.2 Managing Sensor Usages ...... 75 4.9 Discussions ...... 77 4.9.1 Extending SemaDroid to iOS and BlackBerry OS ...... 77 4.9.2 Mock Sensor Data ...... 78 4.9.3 Coverage of SemaDroid ...... 78 4.9.3.1 Sensor Coverage ...... 78 4.9.3.2 App Coverage ...... 79 4.9.4 Malware Detection and Classification ...... 79 4.9.5 Policy Design and Revocation ...... 79 4.9.6 Overhead Analysis ...... 80 4.9.7 Supporting New Types of Participatory Sensing ...... 80 4.9.8 Limitation of SemaDroid on Android ...... 81

Chapter 5 Abusing Notification Services on Smartphones for Phishing and Spamming 82 5.1 Overview ...... 82 5.2 Related Works ...... 83 5.2.1 Spam Attacks on Smartphones ...... 83 5.2.2 Phishing Attacks on Smartphone ...... 83 5.3 Notification Customization ...... 84

viii 5.4 Phishing and Spam Notification Attacks ...... 86 5.4.1 Phishing Notification Attack ...... 86 5.4.2 Spam Notification Attack ...... 87 5.4.3 Plot ...... 87 5.4.4 Play ...... 88 5.4.5 Cleanup ...... 89 5.5 Proposed Attacks on Android ...... 89 5.5.1 Attack with Toast ...... 90 5.5.2 Attack with Status Bar Notifications ...... 91 5.5.3 Attack Demonstration ...... 91 5.6 Proposed Attacks on BlackBerry OS ...... 92 5.6.1 Attack with Dialog ...... 92 5.6.2 Attack with Message List ...... 94 5.6.3 Attack Demonstration ...... 95 5.7 Proposed Attacks on iOS ...... 96 5.8 Proposed Attacks on Windows Phone ...... 97 5.9 Discussion ...... 98 5.9.1 Stealthiness of Trojan App ...... 98 5.9.2 Stealthy Spam Content Distribution ...... 99 5.9.3 Push Service ...... 100 5.9.4 Incentives of Proposed Attacks ...... 101 5.9.5 Jailbroken iOS ...... 102 5.9.6 Android 4.0 ...... 102

Chapter 6 Defending Notification based Attacks by View Authentication 104 6.1 Semi-OS-Controlled Notification ...... 104 6.2 Notification Logging Service ...... 106 6.2.1 Failure of Android EventLog ...... 106 6.2.2 Proposed Notification Logging Service ...... 106 6.3 SecureView Framework ...... 107 6.4 Heuristic Approaches for Sender Application Identification . . . . . 108 6.4.1 Android ...... 109 6.4.2 BlackBerry OS ...... 109

Chapter 7 Conclusion and Future Works 111 7.1 Conclusion ...... 111 7.2 Future Works ...... 113 7.2.1 Onboard Sensor based Attacks ...... 113

ix 7.2.2 Sensor Management Approaches ...... 113 7.2.3 View Authentication on Smartphones ...... 114 7.2.4 Malware Detection ...... 114

Bibliography 115

x List of Figures

2.1 An example of sensor data collection on accelerometer in Android . 10 2.2 Three types of notification services ...... 13

3.1 An introduction to accelerometer and orientation sensor readings on the Android platform ...... 17 3.2 The attack overview ...... 22 3.3 Acceleration readings in different contexts ...... 24 3.4 The proposed statistic approach for tap event detection ...... 26 3.5 The distribution of P3 of different user on different smartphones . . 27 3.6 Examples of gesture changes when tapping different areas of the touchscreen ...... 31 3.7 An example of HostApp’s screen layout and target screen layouts . 33 3.8 Examples of distinguishing tap events at different positions . . . . . 35 3.9 An example of tap position inference in the number pad logging attack ...... 38 3.10 Evaluation of number pad logging attack ...... 40 3.11 Example of inference distribution table ...... 42

4.1 An overview sensor usage management in SemaDroid ...... 53 4.2 A demonstration of sensor usage report ...... 56 4.3 An example of SemaDroid policy ...... 57 4.4 The design of SemaDroid framework on Android ...... 65 4.5 Enforcing sensor usage policies on sensors managed by SensorMan- ager with SemaDroid ...... 66 4.6 Enforcing SemaDroid Policies on GPS managed by LocationMan- ager on Android ...... 67 4.7 Enforcing SemaDroid policies on Camera when taking pictures . . . 70 4.8 Enforcing SemaDroid Policies on microphone ...... 71 4.9 Enforcing SemaDroid Policies on camera and microphone when recording video clips ...... 72 4.10 Implementation of SemaDroid on Android ...... 76

xi 4.11 Implementation of SemaDroid on Android ...... 77

5.1 A comparison of OS-Controlled and App-Controlled notification views 85 5.2 Phishing and spam notification attack scenarios on Android 2.3 . . 90 5.3 Phishing notification attack scenarios on BlackBerry OS 7 ...... 93 5.4 Dialog and Message List based spam notification attack scenarios on BlackBerry OS 7 ...... 95 5.5 A spam notification shown in the Notification Center of iOS 5 (Notish is exposed in the notification view) ...... 97 5.6 A spam notification on Windows Phone 7.1 ...... 98 5.7 Demo of spam notification attack on Android 4.0 ...... 103

6.1 The App-Controlled notification view allows view customization but is lack of sender authentication information; The OS-Controlled notifica- tion view (e.g. iOS) is immune to proposed notification attacks but lim- its the capacity of app developers. The proposed Semi-OS-Controlled notification view supports view customization and is immune to notifi- cation attacks...... 105 6.2 Proposed defense mechanisms ...... 108

xii List of Tables

1.1 A summary of experimental results(!means feasible and #means infeasible) ...... 6

2.1 Percentage of apps using sensors within the collected Android apps 10 2.2 Notification services on smartphone platforms ...... 13

3.1 Specifications of selected smartphones ...... 18 3.2 Experimental results of tap event detection ...... 30 3.3 The results of screen lock attack ...... 43

4.1 Enforcement rules supported by SemaDroid on different sensors (variables in () are parameters) ...... 59

xiii Acknowledgments

I would like to express my deepest appreciation to my supervisor Dr. Sencun Zhu for his support throughout my dissertation research. Dr. Zhu has created a motivating, free, and innovative research environment that I have benefited a lot such as the valuable research experience and expertise. Without all his guidance and help, this dissertation would not have been possible. It has been a great pleasure and honor for me to work under his supervision. I am also grateful to Dr. Tom La Porta, Dr. Guohong Cao, and Dr. Dennis Lin for attending my Ph.D. dissertation committee and providing the great inspiration and insightful comments on my dissertation. Moreover, I would like to thank my co-author Kun Bai, Bo Zhao, Xin Chen, Hungyuan Hsu, Leslie Liu, and Randy Moulic for numerous discussions, insightful suggestions, and spending valuable time helping me on my research works. Last, but definitely the most important, I am greatly thankful for my parents and my fiancee. I am deeply indebted to them for spending so many years in the Ph.D. program. Their love, encouragement, understanding, and support give me strength and courage.

xiv Chapter 1

Introduction

1.1 New Features on Smartphones

Today smartphones are proliferating. The Gartner’s mobile sales report in the second Quarter, 2012 [1] shows that over one-third (36.7%) of all mobile devices sold in the second quarter of 2012 were smartphones and sales of smartphones were up by 42% compared to a year ago. According to the IDC’s 2nd Quarter, 2012 statistics [2], more than 154 million devices are sold across the major smartphone platforms between April and June 2012 . A Nielsen report [3] also estimates that almost half (49.7%) of U.S. mobile subscribers now use smartphones, as of February 2012. According to Gartner’s analysis [1, 4], the major smartphone platforms include Andriod [5], iOS [6], Windows Phone [7], and BlackBerry OS [8]. One important reason that makes smartphones endorsed by both consumers and third party application developers are the innovative features the modern smartphone platforms provided. Among those features, embedded sensors and notification services are two extremely popular types of features that exist on almost every smartphone device. Embedding various types of sensors are one of the most important feature that distinguish the smartphone platforms from their ancestor dumbphones and the traditional computer systems. For example, the Apple iPhone 4s [9] includes eight different sensors:accelerometer, GPS, ambient light sensor, dual microphones, prox- imity sensor, dual cameras, compass, and gyroscope. Besides these eight sensors, the competitor Google’s Nexus Galaxy [10] also provides a near field communica- 2 tion (NFC) sensor. These sensors are very useful in improving the user interface, providing location-based services, as well as gathering data about user and their environments. For example, the GPS enables new location-based applications in- cluding the location search, navigation, mobile social networks; light sensors are used to adjust the brightness of the screen; cameras and microphones are used to take pictures, make videos, and record sounds; and NFC sensors have been used to support mobile financial applications such as Google Wallet [11]. The notification service is another popular feature that allows a notification sender application to notify the smartphone user with a notification view when a trigger event happens. Common notifications include system update notifications, battery shortage notifications, news update notifications, and calender reminder notifications. To facilitate customization for developers, many smartphone plat- forms support highly customizable notification services, which allow the third party applications to specify the trigger events, the notification views to be displayed, and the allowed user operations on the displayed notification views. In this dissertation, our studies focus on the security and privacy issues of installed third party applications on smartphones with onboard sensors and the notification services. Both onboard sensors and notification services are accessible by third party applications installed on the smartphone. Accessing certain types of onboard sensors, e.g., GPS and camera, may require corresponding security permissions granted by the user. Accessing notification service currently requires no security permission on major smartphone platforms.

1.2 Motivation

Today’s smartphones are equipped with various embedded motion sensors, such as the accelerometer, gyroscope, and orientation sensors [12]. These motion sen- sors are used to gauge the smartphone’s status of motion, such as orientation, acceleration, and direction. They are useful in supporting the innovative mobile UI [13], context awareness [14, 15], and motion-based commands(e.g., shuffling songs [16]). Probably due to the assumption that data collected by motion sensors is not sensitive, so far third party applications are allowed to access the readings of embedded accelerometer and orientation sensors without any security permission 3 requirements on all Android [17], iOS [18], and Blackberry [19]. As the use of motion sensors in mobile devices has become more widespread, serious concerns have been raised about the potential risks of a user’s private information from being leaked through an installed third party application which explores these motion sensors. Recently, Marquardt et al. [20] presented a spying application (sp)iPhone which utilizes the vibrations sensed by a smartphone to infer the user inputs on a nearby keyboard. Other works including [21, 22, 23, 24] proposed motion-based side channels for inferring keystrokes on the smartphone touchscreen. Such security and privacy exposures threaten to stifle the adoption and acceptance of these applications and even the smartphone platforms [25]. Similarly, notification customization has been widely endorsed by both users and the developer communities. However, an installed third party application may abuse the notification customization to send anonymous notifications or fraudulent notifications. The anonymous notifications can be used to distribute unsolicited advertisements, and the fraudulent notifications can be used to launch phishing attacks against other installed applications. For example, a trojan application may generate a fraudulent notification that mimics the Facebook notification and leads the user to a fraudulent Facebook login view. To secure the smartphone platforms, many mature approaches and experi- ences for securing traditional computer systems and dumbphones have been im- plemented on current smartphone platforms, such as the permission-based access control [26, 27], the PIE (Position Independent Executable) technique [28], and the cryptographic service [29]. However, features, such as onboard sensors and notification service, are newly introduced on smartphones and have not been thoroughly studied yet. The existing approaches cannot help to prevent abusing the new features by malicious third party applications. Such attacks will threaten the security of smartphone platforms and cause private information leakages of user’s private information.

1.3 Contributions

In this dissertation, we study the security and privacy of new features on smart- phones from both the attack side, exploring attack approaches with new features, 4 and the defense side, proposing security mechanisms to prevent new feature based attacks.

1.3.1 Motion Sensor based Logging Attacks

In Chapter 3, we study the feasibility of inferring a user’s tap inputs to a smart- phone with its integrated motion sensors. Briefly, we utilize an installed trojan application to stealthily monitor the movement and gesture changes of a smart- phone using its on-board motion sensors. When the user is interacting with the trojan application, it learns the motion change patterns of tap events. Later, when the user is performing sensitive inputs, such as entering passwords on the touch- screen, the trojan application applies the learnt pattern to infer the occurrence of tap events on the touchscreen as well as the tapped positions on the touchscreen. Specifically, the key contributions of our work in the Chapter 3 include:

• We show the unique patterns of tap events in terms of changes of acceleration of smartphone. With statistical approaches, such patterns may help the installed trojan application to detect the occurrences of tap events.

• We show the correlation between the tap position and the gesture changes during one tap event. With the knowledge about the layout of view displayed on the touchscreen, we show the feasibility of inferring user inputs with observed readings from the orientation sensor during tap events.

• We present the design and implementation of TapLogger, a trojan application that utilizes observed sensor readings to stealthily log the user inputs on the touchscreen. For demonstration, we present two types of attacks on Android: stealing the password of screen lock and logging the PIN number entered during a phone conversation.

1.3.2 Proposed Sensor Management Framework

In Chapter 4, we propose a privacy-aware sensor management framework, called SemaDroid, which extends the existing sensor management framework on Android to provide comprehensive and fine-grained access control over onboard sensors. 5

SemaDroid allows the user to know the sensor usage of every installed application, specify context-aware and quality-of-sensing based access control policies, and en- force the specified policies in real-time. Specifically, the key contributions of our work in the Chapter 4 include:

• The proposed SemaDroid framework provides a comprehensive management covering all sensors on the smartphones, not only those permission-associated sensors on Android.

• SemaDroid first introduces the notion of Quality-of-Sensing (QoSn) to mea- sure the quality of sensor data provided by onboard sensors to sensing appli- cations.

• SemaDroid proposes a QoSn-based sensor usage policy design and enforce- ment.

• SemaDroid provides a Privacy Bargain feature, which allows the user to interactively refine the SemaDroid sensor usage policies basing on the trade- off between privacy and desired functionalities of applications.

• SemaDroid provides a unique Mock Data Generator service that generates continuous mock sensor data for different types of sensors.

• Detailed design and implementation of SemaDroid on Android are presented to show that SemaDroid works compatible with the existing Android OS. Demonstrations are also given to show the capability of SemaDroid on sensor management and on defeating emerging sensor-based attacks. Finally, we show the high efficiency and security of SemaDroid.

1.3.3 Notification based Phishing and Spam Attacks

In Chapter 5, we show that notification customization may allow an installed tro- jan application to launch phishing attacks or anonymously post spam notifications. Through our studies on four major smartphone platforms, we show that both An- droid and BlackBerry OS are vulnerable under the phishing and spam notification attacks. iOS and Windows Phone allow little notification customization, thus 6

Table 1.1. A summary of experimental results(!means feasible and #means infeasible)

Send Anonymous Navigate To Platforms Notifications Fraudulent View Android 2.3 ! ! Android 4.0 ! ! BlackBerry OS 7 ! ! iOS 5 # # Jailbroken iOS 5 ! ! Windows Phone 7.1 # !

launching the phishing and spam attacks will expose the identity of the trojan application. A summary of our experimental results is shown in Table 1.1. Attack demonstrations on all platforms are also presented in Chapter 5. Specifically, the key contributions of our work in the Chapter 5 include:

• We study and compare the notification services on four major smartphone platforms.

• We show the feasibility of launching phishing and spam attacks using the notification services on smartphones.

• We present detailed designs, implementations, and demos on how to launch phishing and spam notification attacks on four major smartphone platforms.

1.3.4 Preventing Notification based Phishing and Spam Attacks

In Chapter 6, we propose three approaches to prevent the phishing and spam notification attacks while still allowing notification customization. The key is to guarantee displaying the sender application authentication information within the notification views. Specifically, the three proposed defense approaches are 7

• For smartphone platforms, we propose a new Semi-OS-Controlled design principle for the notification view. A Semi-OS-Controlled notification view contains a customizable subview controlled by the sender application, and a wrapper frame that is under control of the smartphone platform. To prevent the phishing and spam notification attacks, the wrapper frame contains the authentication information of the sender application.

• We propose a Notification Logging service that records posted notifications with sender authentication information, so that an user can review any posted notifications.

• We propose a view authentication framework, named SecureView, which en- ables a third party application to protect itself from becoming the victim of phishing notification attacks by adding an authentication image and text to its sensitive views.

1.4 Dissertation Outline

In summary, the rest of dissertation is organized as follows. An overview of onboard motion sensors and notification services on smartphones is given in Chapter 2. The motion sensor based tap logging attacks are presented in Chapter 3. The proposed sensor management framework, SemaDroid, is presented in Chapter 4. In Chapter 5, we study the feasibility of launching phishing and spam notification attacks on different smartphone platforms. With insights learnt, we proposes three approaches to prevent notification based phishing and spam attacks in Chapter 6. Finally Chapter 7 concludes our studies and present future works. Chapter 2

Onboard Sensors and Notification Services on Smartphones

In this chapter, we explain the preliminaries and introduce background concepts of onboard sensors and notification services on smartphones. The term apps has been widely used to refer applications designed to run on smartphones. In this dissertation, we make the term application and app interchangeable to facilitate our discussions. Further, in the explanation of mobile phone sensing, we adopt the specification and terminology defined on the Android platform as Android is the most popular and most exploited smartphone platform. Most important, the Android Open Source Project [30] allows us to study and modify the source code of Android kernel. While this is infeasible on other smartphone platforms, such as iOS and BlackBerry OS. In the explanation of notification services, we examine all four major smart- phone platforms as the proposed notification based attacks rely on installed trojan application not related to the kernel. Due to the same reason, the implementation of our proposed defense approaches are also implemented on Android. 9

2.1 Mobile Phone Sensing

2.1.1 Types of Onboard Sensors

According to the associated security permissions, we classify sensors on Android into two groups, unrestricted sensors and restricted sensors. Accessing unrestricted sensors requires no security permission. These types of sensors are all governed by the SensorManager system service on Android; whereas accessing restricted sensors requires the sensing app to declare corresponding security permissions in its Manifest file (e.g., CAMERA). Each type of restricted sensor has its specific sensor management service, e.g., the LocationManagerService for GPS. Below we list all the sensors considered1

• Unrestricted sensors include accelerometer, ambient temperature sensor, gy- roscope sensor, gravity sensor,light sensor, magnetic field sensor, orientation sensor, atmosphere pressure sensor, proximity sensor, relative humidity sen- sor, and temperature sensor.

• Restricted sensors include GPS, camera, and microphone.

To investigate the popularity of sensor usages, we downloaded more than 12, 000 top ranked free apps from 7 popular categories in the Google Play App Store. Static analysis is then performed with the help of reverse engineer tool, apktool [32] to analyze the sensor usages of every apk downloaded. The number of apps down- loaded from each category is slightly different. For example, the comics category in Google lists much fewer apps than the game category. As we listed in the Ta- ble 2.1, the Game category is the category that accesses sensors most, and the GPS category is the most popular sensor type. Overall, from the dataset we collected, accessing onboard sensors (e.g., GPS and unrestricted sensors) is a common be- havior of third party apps. As presented in Table 2.1, the average sensor usage

1Communication sensors are not considered in this dissertation, such as cellular network, wifi, bluetooth, and NFC. Also, touchscreen is not included because, on Android, only the app running in foreground and displayed on the touchscreen is allowed to receive touch event information from the touchscreen. Furthermore, featured sensors, such as the fingerprint reader [31], are not considered as they have only been equipped on few smartphone models and are not supported by standard Android SDK. Battery sensor is also unrestricted and is managed by a separate service, called BatteryService 10

Table 2.1. Percentage of apps using sensors within the collected Android apps

Category Unrestricted GPS Camera Mic- sensors phone Game 53.57% 57.92% 20.81% 2.52% Business 15.77% 54.73% 12.24% 2.98% Book & Reference 7.91% 47.84% 2.38% 0.15% Comics 25.85% 33.47% 12.24% 2.98% Communication 15.62% 38.51% 9.76% 6.43% Education 16.67% 42.01% 6.96% 6.39% Entertainment 14.24% 40.13% 5.61% 3.41% Average 22.65% 47.89% 11.39% 2.52%

is around 22.56% for accessing unrestricted sensors, around 47.89% for accessing GPS, around 11.39% for accessing camera, and around 2.54% for accessing micro- phone. In Chapter 3, we present more details about the connections between motion sensor readings and user behavior on the touchscreen.

2.1.2 Phone Sensing Applications

Phone sensing applications rely on sensing apps installed on smartphones to col- lect sensor data from onboard sensors [33]. Those collected sensor data may be consumed locally (e.g., supporting game controls) or forwarded to a more powerful remote server (e.g., the earthquake detection application [34]).

Consumer SensorManager ListenerDelegate SensorThread & App Thread Accelerometer Driver registerListener < sensorEventListener, < sensorEventListener, accelerometer, accelerometer, < sampleRate > sampleRate > sampleRate >

A Sensor Event A Sensor Event A Sensor Event (to

Figure 2.1. An example of sensor data collection on accelerometer in Android 11

In Figure 2.1, we use an example of accessing the accelerometer to briefly ex- plain the procedure of sensor data collection on Android. To request sensor data from accelerometer, the installed sensing app first sends a registration request to the SensorManager system service. In the request, the sensing app specifies the type of desired sensor (i.e., accelerometer), the (recommended) sample rate, and the SensorEventListener that is implemented within the sensing app. Upon re- ceiving the request, the SensorManager creates a ListenerDelegate thread for this sensing app, passes the parameters to the thread, and then maps the thread to a SensorThread which receives sensor events from the accelerometer driver. For accelerometer, a sensor event includes a vector of sampled values[] and a times- tamp of sampling. The sensor event will be passed backwards to the designated SensorEventListener in the sensing app. The procedures of sensor data collection on other sensors are similar to that of accessing the accelerometer. Furthermore, accessing certain sensors may require certain security permissions. In Chapter 4, we present studies focusing on the management of sensor data collection performed by installed third party apps. We present the details about the sensor data collection on different types of onboard sensors in Section 4.7.

2.1.3 Existing Sensor Management on Android

The existing sensor management system on Android relies on a general permission- based access control system. During the installation of a sensing app, the smart- phone user will be notified of security permissions claimed by this app. The installation can pursue only if the user agrees to grant all the claimed security permissions. If an app attempts to access a sensor whose security permissions are not included in the Manifest file of app, the access attempt will be denied by Android OS and a security exception will be thrown. Clearly, the existing permission-based access control system is not suitable for sensor management as it only provides management on the access privileges without any management on the sensor usage. Because Android supports multitasking, installed apps running in the background can stealthily collect sensor data from desired sensors, as long as the sensors are unrestricted or the corresponding security permissions have been granted. 12

2.2 Notification Services

2.2.1 Notification Categorization

A notification is a message dialog that is shown on the surface of a smartphone screen. To send a notification, the sender application first prepares a notification object and registers a trigger event for it. When the trigger event occurs, this notification will be fired. As the notification service is a common service with almost no abuse reported yet, accessing notification service requires no security permissions on most smart- phone platforms, such as Android, BlackBerry OS, and Windows Phone.1 Despite the differences in designs and implementations, notification services on existing smartphone platforms can be categorized into three types (shown in Figure 2.2 and Table 2.2):

• Pop-up Notification notifies the user by popping up a notification dialog on screen, e.g., the Toast Notification on Android and Dialog Notification on BlackBerry OS.

• Status Bar Notification adds a notification view as a status bar at the top of screen, e.g., the Message List on BlackBerry OS 7, the Status Bar Notifica- tion on Android, and the Notification Center on iOS 5.

• Icon Notification shows the notification by making changes on the icon of a sender application in the main menu, e.g., the Badge Notification on iOS 5 and the Icon Update function on BlackBerry OS 7.

In Chapter 5, we focus on launching phishing and spam attacks with pop-up notification and status bar notification. The icon notification is not applicable because it will expose the identity of the sender application.

2.2.2 Notification Customization

To facilitate the application development, many smartphone platforms allow the third party applications to send customized notifications. Despite the differences

1iOS requires the third party applications to explicitly request permissions from the user for push notification service after installations 13

Figure 2.2. Three types of notification services

Table 2.2. Notification services on smartphone platforms

Pop-up Status Bar Icon Platforms Notification Notification Notification Android 2.3 Toast Status Bar # Android 4.0 Toast Status Bar # BlackBerry OS 7 Dialog Message List Icon iOS 5 Alert Notification Center Badge Windows Phone 7.1 ShellToast # Tile

in the design and implementation of different smartphone platforms, a notification can be described by three elements: the Trigger Event that fires the notification; the Notification View that is displayed on the screen; and the Allowed User Op- erations that defines the invoked actions when a user operates on the displayed notification view. With respect to the allowed customization in the notification service, the se- lected four smartphone platforms fall to two extremes. On Android and Black- Berry, the sender application is given the full control over the displayed notifi- cation view as well as the invoked actions corresponding to user’s operations on 14 the notification view. For example, Android and BlackBerry allow third party applications to submit a customized view object in the notification view. iOS and Windows Phone, being less customizable, only allow submitting text content. On all these four smartphone platforms, a sender application can trigger notifications when it is not running in the foreground. In Chapter 5 we show that the notification customization may also allow an installed trojan application to anonymously distribute spam notifications or launch notification based phishing attacks. Then, in Chapter 6, defenses approaches are proposed for the Android platforms in order to prevent notification based phishing and spam attacks. Chapter 3

Inferring User Inputs on Touchscreens Using Motion Sensors

Smartphones are shipped with various embedded motion sensors, such as the ac- celerometer, gyroscope, and orientation sensors. These motion sensors are useful in supporting the mobile UI innovation and motion-based commands. However, they also bring potential risks of leaking user’s private information as they allow third party applications to monitor the motion changes of smartphones. In this chapter, we explore the feasibility of inferring a user’s inputs on the smartphone touchscreen using sensor data collected from motion sensors. Our work is based on the observed correlations between the tap events and the motion change of smartphone. First, during a tap event, the acceleration of smartphone will change caused by the force from finger on the touchscreen. The change of acceleration follows certain patterns that can help the installed trojan application to detect the occurrences of tap events. Second, tapping different positions on the touchscreen will cause small, but discernable changes of gesture of smartphone by the sensors. For example, tapping on the left side of touchscreen may cause the smartphone to turn left while tapping on the right side may cause the smartphone to turn right. By observing the gesture changes during a tap event, the attacker may roughly infer the tapped position on the touchscreen. The inferred position may not be precise. However, if the attacker knows the context of tap events and the layout of current view on the touchscreen, he may be able to infer the user’s inputs (e.g., the pressed number 16 button) with the inferred tap position.

3.1 Technical Background

3.1.1 User Inputs on Touchscreen

The touchscreen is the primary user interface of a touch-capable smartphone, and it presents a target of opportunity for potential hackers and information thieves. When a user taps on the touchscreen, the display and its supporting hardware and firmware will report the coordinates of tap events to the operating system of the smartphone. The coordinates of a tap event together with knowledge of the ap- plication view currently displayed on the touchscreen determine the corresponding user input. For example, a tap event with coordinates within the boundary of a button displayed on the touchscreen stands for a tap action on this button. As the layout of many views are public and uniform, such as the layout of screen lock view shown in Figure 3.7, the coordinates of tap events become extremely sensitive. To protect user inputs from being eavesdropped, there are rigorous restrictions on the receiver who is allowed to receive the tap events and their coordinate in- formation. For example, on the Android platform, only the view that is focused and currently being displayed on the touchscreen will be allowed to receive the coordinate information [35]. Therefore, a third party application running in back- ground (e.g., a service) can never receive the coordinate information when the user is tapping the touchscreen to unlock the smartphone with passwords or dial a number during a call.

3.1.2 Motion Sensors

Motion sensors embedded in smartphones offer the hacker a side channel into a user’s mobile device, from which he/she may steal private data. Specifically, we refer to the onboard accelerometer and orientation sensors, which are two of the most commonly equipped motion sensors on commodity smartphones. Up to the most recent version of major platforms, e.g., iOS [18], Android [17], and Blackberry [19], accessing these two sensors requires no security permissions, and enables considerable accesses by a third party application to the underlying resources in 17

Figure 3.1. An introduction to accelerometer and orientation sensor readings on the Android platform the mobile device. As Android is the most popular and most exploited smartphone platform, we adopt the specifications and terminologies defined on the Android platform in this chapter.

3.1.2.1 Accelerometer Sensor

The accelerometer sensor monitors the current acceleration of a smartphone along three axes: left-right(i.e., lateral or x-axis), forward-backward (i.e., longitudinal or y-axis), and up-down (i.e., vertical or z-axis) [36, 17]. The returned readings of the accelerometer sensor are the rates of change of velocity with time along these three axes in m/s2. In Figure 3.1, we illustrate the mapping of axes in relation to a smartphone that is placed horizontally. As described in this figure, the reading of x-axis acceleration would be positive if the smartphone is moving toward the right side; the reading of y-axis acceleration would be positive if the smartphone is moving in the direction of the top of smartphone; the reading of z-axis acceleration would be positive if the smartphone is being lifted. For instance, when placing the smartphone statically and horizontally on a surface as shown in Figure 3.1, the readings of x and y-axis will be zero and the reading of z-axis will be the earth gravity (i.e., 9.8m/s2) because the surface is supporting the smartphone. When the smartphone is dropping freely, the readings of all axes will be zero. To facilitate our discussion, we represent the current acceleration A of a smart- ⃗ phone by a vector A = < Ax,Ay,Az > =Axˆx+Ayˆy+Azˆz,where ˆx,ˆy,and ˆzare the 18

Table 3.1. Specifications of selected smartphones

Model Touch Screen Size Acc. Sample Ori. Sample Android (pixels) Rate Rate Aria W (320) × H(480) about 50 Hz about 50 Hz v2.3 Nexus W (480) × H(800) about 25 Hz about 25 Hz v2.3 Atrix W (540) × H(960) about 95 Hz about 8 Hz v2.3

unit vectors in the directions of positive x, y, and z axes, respectively.

3.1.2.2 Orientation Sensor

The orientation sensor tracks the changes of orientation and gesture of smartphone along three dimensions: Azimuth (x-axis), Pitch (y-axis), and Roll (z-axis) [36, 17]. The returned readings of the orientation sensor are the current gesture of the smartphone in these three dimensions. Each reading is measured by degrees. As illustrated in Figure 3.1, the reading of x-axis is 0o when the smartphone is facing north and the reading changes between 0o and 360o; the reading of y-axis is 0o when the touchscreen side faces to the sky and the reading changes to −/ + 180o when facedown; the reading of z-axis represents the sideways tilt between −90o and +90o.

3.1.2.3 Hardware Specifications

Hardware specifications, such as the sensor sample rate, are important to sensing applications. Different smartphone platforms have different hardware specifica- tions. The brief specifications of three selected smartphone platforms are listed in Table 3.1. As the orientation sample rate of Motorola Atrix is too low, in this chapter, we presents experimental results on HTC Aria and Google Nexus (One).

3.1.3 Tap-To-Open/Active Interactive Pattern

Many interactive patterns exist for using touchscreens. In this dissertation, our threat model is based on the “Tap To Open/Active” pattern [37] which is almost the simplest but most used interactive pattern. With this pattern, a user taps in 19 a specific position of the touchscreen to trigger a feature or to respond, similar to clicking with a mouse. With advanced hardware supports, some latest smart- phones may support multi-touch touchscreens and more complex patterns, such as “Drag To Move” and “Slide To Scroll”. However, in this dissertation, our focus is the “Tap To Open/Active” pattern because of its extreme popularity as well as simplicity. The typical scenario we consider here is that a user holds the smartphone with her left hand and taps the touchscreen using the forefinger of her right hand. Con- sider a tap event on the touchscreen that is face up. The motions of smartphone during one tap event can be briefly described as the three consecutive phases: Ac- tion Down→ Hold→ Action Up: when the user presses down on the touchscreen (i.e., in the Action Down phase), the smartphone will be forced to move down- ward. When the Action Down is over; the smartphone will stop (i.e., be in the Hold phase); Then, the user lifts his finger and the hand holding the smartphone will respond by lifting the smartphone back to its original position (i.e., in the Action Up phase). The whole tapping action is usually performed in a short time period. According to our measurements, a swift tap event is about 50 ∼ 70 ms and an ordinary tap event is about 180 ∼ 220 ms. In our discussion, we name the time duration of a tap event as a SigW in, representing the time duration when the finger is in touch with the touchscreen (i.e., between Action Down and Action Up).

3.2 Related Work

3.2.1 Logging Attacks on Smartphones

Several logging attacks have been proposed to get user inputs on smartphones. Compromising the operating system [38] or hijacking the touch event with fake user interface [39] are straightforward, but they are complex and easy to be detected. Luring the user to install malicious input method applications is another approach. However, the functionality of input method applications is restricted and the user will be warned before installing such applications [40]. [41] studies the feasibility of identifying the password pattern of screen lock by examining the smudges left 20 on touchscreen after usage. Besides, [42] and [43] propose shoulder surfing attacks which infer user inputs by observing a user’s actions on the touchscreen with a camera. In this work, we utilize the (relatively) insensitive motion sensor readings to in- fer the sensitive coordinate information of tap events. As shown in Section 3.6, no specific security permission is required to launch the attack (except the Network- ing permission required to send the user inputs back to attack server). Moreover, TapLogger is automatic in both the training and logging phases. The attacker does not need to be close to the victim user (as in the shoulder surfing attacks) be- cause TapLogger will stealthily perform the logging attack and transfer the inferred inputs back to the remote attack server.

3.2.2 Attacks Relying on Mobile Sensors

The privacy concerns on sensitive mobile sensor data have been raised for some while [44, 45, 46]. Besides the location tracking attacks [47, 48, 49], recent attacks show that the video camera on smartphones might be controlled by an installed trojan app to stealthily record the surrounding when a user enters a building[50] that requires security clearance, credit card and pin numbers can be stolen by a trojan malware which controls the microphone in a smartphone when a user speaks his credit card number to phone menu systems [51]. All these attacks rely on well-known sensitive sensors, such as GPS, microphone, and camera. Access- ing these sensitive sensors requires security permissions granted by users. Different to existing works, our attack is based on motion sensors that are usually consid- ered insensitive and can be accessed by the background services with no security permissions. Thus, the proposed attack is stealthier and more difficult to detect. With motion sensors, [52] presented a proof-of-concept of location inference attack that infers the location changes of a vehicle on a city map basing on the accelerometer sensor measurements collected from the driver’s smartphone. [20] introduced a spying application, named (sp)iPhone, which utilizes the sensed ac- celerometer readings on a smartphone to infer the user inputs on a nearby key- board. The work most similar to TapLogger are [21] and [24]. [21] observed the correlation between tap event positions and motion changes of smartphone, and 21 validated the observation via a data collection application. [24] divided the touch- screen into zones and studied the feasibility of inferring tapped zones basing on readings collected from accelerometer. However, the differences between TapLog- ger and [21, 24] are significant. First of all, TapLogger proposes a new approach for tap event detection which is not discussed in [21, 24]. Secondly, compared to that in [21], TapLogger applies different features extracted from orientation sensor readings in the tap position inference. [24] extracted features from accelerometer sensor readings only. Thirdly, we present the complete design and implementation of a trojan which includes a stealthily training phase as well as two practical at- tacks. Last but not the least, we further showed how the user and device factors impact on the accuracy of logging attacks.

3.3 Attack Overview

3.3.1 Assumptions

On the Android platform, a third party application must explicitly and statically declare the permissions for sensitive resources needed, such as networking and au- dio recording permissions. As motion sensors are considered as insensitive resource, TapLogger does not require any security permission to access the accelerometer and orientation sensors. However, T apLogging requires the Internet permission to send inferred user inputs to a remote attacker, and the Phone Status permission for context awareness. Both the networking and Phone Status permission are very common ones, which are also required by most of popular apps, such as Angry Bird [53], Facebook [54], and Kindle [55]. Therefore, TapLogger would have very little chance to draw attention with respect to security permissions.

3.3.2 Attack Goals

The target in our work is the meaningful user inputs, e.g., the button that is pressed during a tap event, instead of the precise coordinate of a tap event. Inferring the precise coordinate is practically infeasible due to interference factors, such as background noise. However, a button usually covers a zone in the screen and all user’s tap events within this zone corresponding to the same user input. Thus, 22 with knowledge about the layout of a target view, e.g., the one in Figure 3.7, the attacker can infer the user inputs (e.g., the button that is pressed) instead the precise coordinate of a tap event.

Training Mode One Training Tap Event Detected by HostApp Tap coordinate (40, 100)

250 15 x 200 10 z Orientation 150 - Accelerometer 5 y 100 0 x Readings Readings 50 -5 0 z y -10 -50 When the user is 5 10 15 20 0 5 10 15 interacting with Training Data the HostApp 1 2 3 4 5 6 Tap Position 7 8 9 Classifier TapLogger includes Acceleration Pattern learnt for ok 0 del Logging Mode Remote a HostApp and Tap Event Detection Extracted TapLogger sends a SensorListener inferred user Attack Server Features Inferred service inputs to the tap position on attacker One Testing Tap Event detected by ListenerService - the target 250 15 x 200 layout 10 z Orientation 150 Accelerometer 5 y When the user enters 100 0 x Readings Readings 50 -5 passwords by taping the 0 z y -10 -50 touchscreen 5 10 15 20 0 5 10 15

Figure 3.2. The attack overview

3.3.3 Attack Workflow

TapLogger works in two modes: Training Mode and Logging Mode. It switches to the training mode when the user is interacting with the HostApp, and switches to the logging mode when the user is performing sensitive inputs. The context related information can be retrieved from the Android operating system. Briefly, we explain the workflow as shown in Figure 3.2: Training Mode: In the training mode, when the user is interacting with the HostApp, TapLogger can legally receive the coordinates of tap events on the touch- screen, and apply the coordinates with the readings of accelerometer and orienta- tion sensors collected during tap events to generate a user’s interaction pattern. Thus, for one tap event detected in the training mode, the HostApp records related information including (1) the coordinates (on the screen); (2) the times- tamps when it starts and when it ends; and (3) the accelerometer and orientation sensor readings between the start and the end time. The time duration between the start and the end consists a SigW in. The number of collected readings in the SigW in depends on the time duration of tap events as well as the sensor sam- ple rate. In addition, we also collect several readings before and after SigW in, 23 denoted as P reW in and AfterW in, respectively. Logging Mode: In the logging mode, the SensorListener runs in background and keeps stealthily monitoring the readings of accelerometer and orientation sensors. When the user is performing sensitive inputs, the acquired pattern can be applied to infer the tapped area (i.e., zone) on the touchscreen based on sensor readings collected by the SensorListener service. Then, with the knowledge about the layout of a targeted view, TapLogger can then infer the corresponding user inputs. To reduce battery consumption and false positives, the SensorListener service only works in certain sensitive contexts.

3.3.4 Challenges

To make the proposed attack feasible, several challenges exist, which will be ad- dressed one by one in the following sections.

• How to detect the tap events in the logging mode? An approach is needed for SensorListener to identify the tap events in the logging mode by observing the readings of accelerometer and orientation sensors only in the background.

• How to infer the user inputs on the touchscreen based on observed sensor readings? A tap position classifier is needed to help the attacker to infer the tap positions and their implicated user inputs.

• How to design and implement TapLogger that is able to perform the proposed attack stealthily and efficiently? The trojan application should require as few permissions and workload as possible to launch the attack.

3.4 Tap Event Detection

In this section, we first introduce the unique change pattern of acceleration readings during tap events, and then show how to build the user’s pattern in the training mode and how to apply the pattern in the logging mode. 24

3.4.1 Observed Pattern of Tap Events

Accelerometers on smartphones have been widely exploited by context-aware appli- cations to infer the current contexts of smartphones, such as transportation mode inference (i.e., inferring if the user is walking or taking vehicles [56, 57]) and activity recognition (i.e., inferring if the user is walking, sitting, or running [58, 59]). Differently, in our application, our goal is not in the context inference but in detecting the occurrences of tap events. These tap events are comparatively small fragments in the sequence of collected readings, thus existing context inference approaches do not work in our case. To detect the tap events, we utilize the unique change pattern of external force on the smartphone during tap events. To measure the change of the external force F , we use the term SqSum to denote the 2-norm of acceleration vector, i.e., | |2 2 2 2 SqSum= A = Ax + Ay + Az. Obviously, SqSum represents the force on the smartphone and is directly proportional to |F |2. When the smartphone is held statically in one hand, the value of SqSum is equal to the square of gravity, i.e., G2 ≈ 9.82. When the smartphone is dropping freely, the value of SqSum is 0. In Figure 3.3, we show the measured SqSum readings when the user is per- forming different activities. As shown in this comparison, when the user is tapping buttons shown in the touchscreen, the fluctuation of wave is much smaller. This is reasonable because the user will subconsciously stabilize the smartphone when he taps buttons on the touchscreen.

800 800 800

700 700 700

600 600 600 2 500 2 500 500 2

400 400 400

SqSum = |A| SqSum= 300 300 |A| SqSum =

300 |A| SqSum =

200 200 200

100 100 100

0 0 0 0 50 100 150 200 250 300 350 400 450 500 0 50 100 150 200 250 300 350 400 0 50 100 150 200 250 300 350 400 Index of sensor readings Index of sensor readings Index of sensor readings (a) running (b) walking slowly (c) entering passwords by (Smartphone in the pocket) (Smartphone in the pocket) tapping while sitting

Figure 3.3. Acceleration readings in different contexts

Admittedly, the tap event detection will be difficult when the background noise is great. Some background noise may also generate acceleration patterns similar to 25 tap event patterns. To lower the interference caused by background noise, TapLog- ger collects data for both training and logging attacks only when the background noise is small. A simple approach to measure the background noise is to calculate the standard deviation of the latest SqSum readings. TapLogger collects data when the standard deviation is small. Other activity recognition approaches [58] can also be applied to prevent collecting data in noisy environments. Further, TapLogger only starts the ListenerService when in sensitive contexts, e.g., during a phone conversation. In this way, we greatly avoid false triggering.

3.4.2 Proposed Statistic Approach

Based on the observed pattern of tap events, we propose a statistic approach for tap event detection by monitoring the change of force on the smartphone. Specifically, we describe the pattern of tap events by a set of statistic features in terms of SqSum readings. For each feature, TapLogger learns its pattern interval through the training data collected by the HostApp in the training mode. These learnt pattern intervals are user specific representing a user’s pattern of tap events. When TapLogger is in the logging mode, the SensorListener service monitors the acceleration of smartphone by keeping a monitoring window for a sequence of the latest SqSum readings. If the features extracted from the readings of the monitoring window fall in the learnt pattern intervals, the SensorListener will consider a tap event having been detected. The SigW in of a detected tap event is within the monitoring window.

3.4.2.1 Pattern Learning in Training Mode

The unique ↘↗ pattern of SqSum in the Action Down phase is the key to tap event detection in our case. As shown in the enlarged figure of a tap event in Fig- ure 3.4(a), the SqSum readings will first go down and then jump up dramatically corresponding to the first Action Down phase in the Tap-To-Open/Active inter- active pattern. The rest part of tap events represents the motion of smartphone when the user lifts up his finger from touchscreen. The jitter represents the case when the hand holding the smartphone is trying to stabilize the smartphone after the tap event. 26

To catch the unique patten of tap events, we first identify the start and the end of SigWin by the timestamps of received events Motion.Event.ACTION DOWN and Motion.Event.ACTION UP, respectively. Then, we extract five features from the readings of SqSum within the identified SigWin:

• P1: The peak reading of ↘↗ at the end of Action Down minus the base,

i.e., the value of SqSumpeak − base;

• P2: The trough reading of ↘↗ of Action Down minus the base, i.e., the

value of SqSumtrough-base;

• P3: Difference between the peak and the trough readings, i.e., the value of

SqSumpeak-SqSumtrough;

• P4: Time gap between peak and trough, i.e., the time gap as T imepeak-

T imetrough;

• P5: The standard deviation of the entire SigW in, i.e., Std(SigW in);

150 observed sensor readings 150 checkpoint observed sensor readings 140 base value = 9.8 2 140 base value=9.8 2 130 130 120 120 Identified Identified 110 start of SigWin end of SigWin 110

100 100

90 90

80 80

SqSum generated from accelerom eter readings eter accelerom from SqSumgenerated First trough Identified

SqSum genereted from accelerom eter readings eter accelerom from SqSumgenereted 70 70 SigWin (size=15) 60 60 0 2 4 6 8 10 12 14 16 18 20 22 24 25 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 Index of sensor readings Index of sensor readings (a) Extracting features from a tap event in the (b) Evaluating a tap event in the logging mode training mode

Figure 3.4. The proposed statistic approach for tap event detection

We briefly explain these measures as follows: base = G2 denotes the SqSum

value when the smartphone is placed statically with no external force on it, P1 27

measures the magnitude of force when pressing down, P2 measures the magnitude of force from the hand holding the smartphone when reacting to the tap event, P3 and P4 measure the change rate, and P5 measures the fluctuation. Each tap event is described by these five features in the tap event detection. With all tap events detected in the training mode, TapLogger learns the distri- butions of these features for the current user on the current smartphone. According to our measurements in experiments, the distributions of these five measures form bell-shaped curves that are close to normal distributions. Thus, with the measure- ments in our training dataset, we take the range between the Lower Extreme and the Upper Extreme [60] of each measurement, represented by [L, U], to describe the pattern interval of this measurement. Specifically, L = Q1 − 1.5 × IQR and

U = Q3 + 1.5 × IQR, where Q1 is the lower quartile, Q3 is the upper quartile, and

IQR = Q3 − Q1 is the interquartile range. In this way, the pattern for tap event detection can be presented by five sets of boundary values, i.e., PS={I1,I2,I3,I4,I5}, where Ii = {Li,Ui}. Different people have different tapping patterns.

140

120

100

m 80 u S q S 60

40

20

0 A(Atria) A(Nexus) B(Aria) B(Nexus) C(Aria) C(Nexus)

Figure 3.5. The distribution of P3 of different user on different smartphones

3.4.2.2 Tap Event Detection in Logging Mode

When TapLogger is in the logging mode, the SensorListener service detects tap events by observing the readings of accelerometer. Services running in background 28

(e.g., SensorListner) are not allowed to receive touch event information from the touchscreen. Specifically, in the logging mode, the SensorListner service keeps a MonitorWin, which contains the last K observed SqSum values of acceleration. In our experiments, TapLogger calculates the average size of SigW in in the training dataset, and sets K twice the average size. The SqSum readings in the MonitorWin are ordered by their generation times. We present an example of MonitorW in in Figure 3.4(b). Whenever a new SqSum reading is generated, the SensorListner service will first update the MonitorWin by adding the new SqSum reading, and then check the SqSum reading at a fixed index position named checkpoint, e.g., the 10th reading in the MonitorWin shown in Figure 3.4(b). The purpose is to check whether the current SqSum reading at the checkpoint is the peak point of the first ↘↗ of a tap event. Basically, assume that the current checkpoint is the peak point of a tap event. The SensorListner will try to identify the corresponding trough point in the Mon- itorWin, extract features P1 ...P5, and check if the extracted features are within the intervals described in the learnt tap event pattern. The checking scheme is illustrated in Figure 3.4(b). The detailed checking scheme for tap event detection is described in the fol- lowing Algorithm 1.

3.4.3 Evaluations

In the evaluation, the tester students were first asked to play the icon-matching game for 30 rounds, collecting a training dataset of more than 400 tap events. With the collected training dataset, TapLogger extracts the proposed five features (i.e.,

P1 ...P5) from each tap event, and generates a statistic pattern for each dataset. These statistic patterns (i.e., boundaries of parameters) are user specific as well as device specific.

For example, in Figure 3.5, we present the distribution of the P3 feature col- lected from training data of different users (i.e. user A, B, and C ) on different smartphones. As shown in this comparison, first of all, most of measured P3 fea- ture falls in the range between the lower extreme and the upper extreme. Secondly, 29

input : PS={I1,I2,I3,I4,I5}, the learnt pattern of tap events, where Ii = {Li,Ui};MWS, the sequence of SqSum readings in the current MonitorW in; output: Indicator, that returns TRUE if a tap event is detected; StartIndex and EndIndex, that returns the estimated start and end of the detected tap event in the MonitorW in, respectively. 2 1 base ← G ; 2 if MWS(checkpoint) − base∈ / I1 then 3 Indicator ← F ALSE; Return Indicator; 4 end 5 StartIndex ← the first reading that is close enough to base starting from the checkpoint to 0 6 trough ← the index of minimum reading between StartIndex and checkpoint in the MonitorW in; 7 if MWS(trough) − base∈ / I2 then 8 Indicator ← FALSE; Return Indicator; 9 end 10 if MWS(checkpoint) − MWS(trough) ∈/ I3 then 11 Indicator ← FALSE; Return Indicator; 12 end 13 if checkpoint − trough∈ / I4 then 14 Indicator ← FALSE; Return Indicator; 15 end 16 EndIndex ← StartIndex + AveLength 17 if std(NWS[StartIndex, EndIndex]) ∈/ I5 then 18 Indicator ← FALSE; Return Indicator; 19 end 20 Return Indicator, StartIndex, EndIndex; Algorithm 1: Tap event detection in logging mode different users have different patterns. The more convergent the distribution of ex- tracted features, the more consistent the pattern. Thirdly, the tap event patterns of the same user are different on different smartphones due to the difference in the hardware, such as the sensor sample rate and weight. In the testing phase, the tester students were asked to enter a sequence of about 150 numbers in a testbed with UI the same as the number pad layout as shown in Figure 3.6. During the testing phase, TapLogger stealthily monitors the accelerometer readings in the background and used the corresponding statistic 30

Table 3.2. Experimental results of tap event detection

User Model Precision Recall F-Measure User A Aria 93.6% 91.8% 92.74% User B Aria 76.3% 90.0% 82.6% User C Aria 70.4% 97.4% 81.7% User A Nexus 99.3% 96.3% 97.8% User B Nexus 74.67% 95% 83.61% User C Nexus 83.97% 88.37% 86.12%

patterns to detect the tap events on the touch screen. The experimental results in Table 3.2 show that the proposed tap event detection approach can achieve high accuracies in identifying the tap events on the touchscreen.

3.5 Tap Position Inference

The goal of tap position inference is to identify the tapped area on the touchscreen. In this section, we first show the correlation between the position of a tap event and its corresponding gesture changes, measured by the orientation sensor. Then, we present a way of dividing the touchscreen into zones (i.e., tapped area) based on layout of the target view. Finally, with real tap events data collected in our experiments, we show the feasibility of distinguishing tap events in different zones. Limitations and reasons are also presented in the end to show the capacity of inferencing using this correlation.

3.5.1 Gesture Change Analysis

When a user taps on the touchscreen using his finger, the gesture of smartphone will change caused by the external forces from the finger and the hand holding the smartphone. The way that the gesture changes is related to the position on the touchscreen that has been tapped. Intuitively, when the user taps on the top of touchscreen, the head of smartphone will go down; while the user taps on the right side of touchscreen, the body of smartphone will lean right as well. TapLogger senses the gesture changes through two types of readings from the 31

10

8

6

4

2

0 Degree -2

-4

-6 Pitch -8 Roll O riginal position -10 0 5 10 15 Index of readings from orientation sensor

10

8

6

4

2

0 D egree -2

-4

-6 Pitch -8 Roll O riginal position -10 0 5 10 15 index of readings from orientation sensor

Figure 3.6. Examples of gesture changes when tapping different areas of the touchscreen orientation sensor: the readings of Pitch, measuring turning left or right of smart- phone; and the readings of Roll, measuring the going down of head or bottom. As shown in Figure 3.6, when the user taps on the top left of touchscreen, the smart- phone will turn left and its head will goes down. Correspondingly, the P itch value goes up because the head goes down, and the Roll value goes up because the face of touchscreen turns left. When the tap event is done, the gesture of smartphone will go back to the approximate of its original gesture. For the comparison, we 32 show the gesture change when tapping on top right in Figure 3.6(2.a). As shown in its corresponding orientation readings, the P itch value goes up because the head goes down, but the Roll value now goes down because the face of touchscreen turns right. Clearly, it would be ideal if one can infer the exact coordinates of tap events based on the observed gesture change of smartphone. However, due to noise and limitation on sensor sample rate, such exact inference is not possible. Instead of inferencing the exact coordinates, TapLogger divides the screen into meaningful zones and infers a zone on the screen that contains the exact coordinates.

3.5.2 Screen Division

We name the view on which the user is performing sensitive inputs as the Target View. In a target view, zones stand for meaningful objects, such as buttons. Therefore, if the attacker can correctly identify the pressed zones, he can get the user inputs on the touchscreen with knowledge about the layout of the target view. In Figure 3.7, we present the layout of two target views: one is the layout of screen lock view on which the user enters the password by tapping buttons; the other is the layout of number pad view on which the user enters his PIN or credit card number when making calls. As we can see in Figure 3.7, the layout can easily be divided into meaningful zones by individual buttons. The zones we are interested in are buttons used to enter the password or PIN. To disguise its purpose, the attacker may also carefully design the user interface of HostApp. For example, in Figure 3.7(1), we present the screen layout of a icon- matching game (i.e., the HostApp). When playing the icon-matching game, the user may not realize that he is contributing training data for the target view in Figure 3.7(2) .

3.5.3 Proposed Inference Approach

With the screen division, we convert the tap position inference problem to a clas- sification problem, in which, each class is a labeled zone in the target view. In the training mode, TapLogger uses the collected training data to create a tap position classifier following the user’s tapping pattern. While in the logging mode, TapLog- 33

(1) An example of screen (2) The target layout: (3) Another target layout: layout of HostApp targeting at the screen lock layout the number pad layout the screen lock layout (to unlock the screen) (to enter PIN or credit card num) (in Training Mode)

Figure 3.7. An example of HostApp’s screen layout and target screen layouts ger uses this trained classifier to infer the corresponding class (i.e., the zone or button). For each detected tap event, the output of classification in the logging mode is an estimated zone that contains its real coordinates.

3.5.3.1 Classifier Generation in Training Mode

Similar to the proposed tap event detection approach, TapLogger keeps monitoring the readings of the embedded orientation sensor. When a tap event is observed by the HostApp, TapLogger first determines the start and end of SigWin by events Motion.Event.ACTION DOWN and Motion.Event.ACTION UP, and then, gen- erates the training data for the classifier from the sequence of orientation sensor readings during this SigWin.

The training data of an observed tap event consists of a vector {L, FO}, where

L is the label of zone containing its associated coordinates, and FO are the set of features extracted from the orientation sensor readings during its SigW in. These extracted features measure the gesture changes, and are generated by changes of the orientation sensor readings in Roll and Pitch during the Action Down phase. 34

Briefly, we list the extracted features as follows:

• F1: the change of Roll in the first monotonic section;

• F2: the change of Roll in the second monotonic section; if Roll in the Ac-

tion Down phase is monotonic as a whole, F2 is assigned 0.

• F3: the change of Roll from the start to the end of Action Down phase;

• F4: the change of Pitch in the first monotonic section;

• F5: the change of Pitch in the second monotonic section; if Pitch the Ac-

tion Down phase is monotonic as a whole, F5 is assigned 0;

• F6: the change of Pitch from the start to the end of Action Down phase;

To explain, Features F1, F2 and F3 help to determine if a tap event is on the left side of touchscreen or on the right side; F4, F5, and F6 help determine if a tap event is on the top of touchscreen or on the bottom. Note that, as shown in Figure 3.6, the changes of both Roll and Pitch may not be monotonic in the Action Down phase. According to our observation in experiments, the reason is that, when the finger first contacts the touchscreen, two types of movements of the smartphone take place in parallel. One type of movement is that smartphone may move down as a whole, and the other type is the gesture change of smartphone. Thus, we separate the change of readings into two consecutive sections in which the change of readings is monotonic.

3.5.3.2 Inference in Logging Mode

In the logging mode, TapLogger also keeps a OriMonitorWin for the latest ori- entation sensor readings. When a tap event is detected by the observed SqSum readings, its SigWin will also be determined. With the start and the end of de- termined SigWin, TapLogger retrieves the sequence of orientation readings within the SigWin from the OriMonitorWin, and extracts features FO from the retrieved orientation sensor readings. These extracted features are supplied to the classifier so as to infer the label of zone that contains the coordinates of this detected tap event. 35

B utton 1 (Left) Button 1 (Left) B utton 1 (Left) Button 3 (Right) 6 B utton 3 (Right) 6 6 B utton 3 (Right) 4 4 4 3

F 0 3

0 F

F3 -2 -4 -4

-8 10 -8 10 15 -8 10 5 10 10 5 10 5 5 5 0 F 0 5 F 0 1 F 0 0 0 2 -5 -5 2 -5 F F -5 F -5 1 2 -5 1 -10 -10 -10 -10 -10 -10

14

Button 3 (Top) 14 B utton 3 (Top) Button 3 (Top)

Button # (Bottom ) B utton # (Bottom ) 13 Button # (Bottom ) 9

10 6 F

4 7 6 F 6

4 F -1 1

-6 50 -2 30 F 50 0 5 F 20 0 -20 5 0 -5 -10 F 0 10 20 -5030 20 F 10 -10 4 -15 -10 -5 0 5 10 15 5 F -20-50 F -15 4 4 0 -20

Figure 3.8. Examples of distinguishing tap events at different positions

3.5.4 Evaluation

The classifier for tap position inference is both user specific and device specific. To show the effectiveness of our selected features in classification, in Figure 3.8, we show three experimental results of distinguishing tap events at different positions based on extracted features. Specifically, Figure 3.8(1) and Figure 3.8(2) compare the experimental results of the same user on different smartphones, i.e., Aria and Nexus; Figure 3.8(2) and Figure 3.8(3) compare the experimental results of differ- ent users on the same smartphone. In both experiments, we collect about 60 tap events on each of 12 buttons on the number pad layout. The experimental results in Figure 3.8 show that the proposed features measur- ing the change of Roll (i.e., {F1,F2,F3}) can help to distinguish tap events on the left side of the touchscreen from those on the right side. The features measuring the change of Pitch) (i.e.,{F4,F5,F6} ) can help to distinguish tap events on the top of the touchscreen from those on the bottom. Further, by comparing the results of Figure 3.8(1) and Figure 3.8(2), we show 36 the hardware factors affecting the accuracy of tap position inference. First of all, the data points in Figure 3.8(1) are more convergent because the sample rate of orientation sensor at Aria is about 50 Hz and is much faster than the 25Hz of Nexus. Secondly, despite its lower sample rate, the comparison between Figure 3.8(1.b) and Figure 3.8(2.b) shows that it is easier to distinguish buttons in the same column on Nexus. One reason is because the size of Nexus is bigger than the Aria, making the gesture changes in Pitch axis more obvious during tap events. Based on the comparison, we see that, besides the user pattern, the inference will be easier on smartphones which are bigger and more sensitive in sensing. Moreover, Figure 3.8(2) and Figure 3.8(3) show the user factors affecting the accuracy of tap position inference. Specifically, Figure 3.8(2.a) and Figure 3.8(3.a) show that, although the patterns of different users are different, the tap events by the same user on different side of touchscreen are still distinguishable. However, the distinguishability is different from user to user. Take user B in Figure 3.8(3) as an example. Figure 3.8(3.a) shows that it is not difficult to distinguish the tap events of user B in the Roll axis. But, in Figure 3.8(3.b), distinguishing tap events by the Pitch axis is difficult. One reason may be that the Arial is small and light, making the gesture change not obvious. Another possible reason is that the way user B holding and tapping the smartphone is different from that of user A. From the perspective of classification, Figure 3.8 also shows the difficulty of distinguishing tap events on neighboring buttons. For example, in the target screen lock layout, many tap events on button 9 may be falsely classified as its contiguous buttons, such as button 12 (i.e., the “Del” button), 8, and 6. One reason of error is that the number of collected sample readings is not enough to describe the gesture changes because of the limited sample rate. The other reason is that the actual tap position is very close to neighboring nodes, making the inference difficult to distinguish correctly. Therefore, in specific attacks, the attacker may apply additional background knowledge to improve the accuracy of inference. Indeed, in the two attacks shown later, we will use different approaches to improve the inference accuracy. 37

3.6 Applications on Android

In this section, we show the detailed design of TapLogger on the Android platform. Further, two types of attacks with evaluations are also presented to show the effectiveness of TapLogger in logging and inferring sensitive user inputs.

3.6.1 Implementation on Android

We have implemented TapLogger as an Android application with the attack flow presented in Figure 3.2. The components of TapLogger on Android include: a HostApp activity, masquerading a benign application (e.g., the icon-matching game); a SensorListener service, collecting readings from sensors in the back- ground; a ContextIdentifier service, starting/stoping the SensorListener service based on the context of smartphone; and a Booter Broadcast Receiver, starting the ContextIdentifier for the context awareness.

3.6.1.1 Training Mode

The HostApp activity starts the SensorListener service when it is brought to the foreground. In the training mode, HostApp logs coordinate information of tap events and the SensorListener service logs the sensor readings during these tap events. Both information are combined at ContextIdentifier and then used as training data for pattern generation in tap event detection and for building the classifier for tap position inference.

3.6.1.2 Logging Mode

In the logging mode, the Booter will be automatically started when receiving the system broadcast (i.e., an Intent) BOOT COMP LET ED, indicting that the boot process of smartphone is complete. Thus, even the user has never started TapLogger after installation, TapLogger can still launch itself when the smartphone is started. Once started, the Booter launches the ContextIdentifier service which determines the current context of smartphone based on the Intents broadcasted by the Android operating system. By identifying the context, the ContextIdentifier services starts the SensorListener service only in a sensitive context. 38

In the end, only the results of inferencing, such as the sequence of labels of pressed buttons, will be sent to a remote attack server. Therefore, the data com- munication overhead for TapLogger is very small.

3.6.2 Number Pad Logging Attack

3.6.2.1 Attack Overview

During phone conversations, a user is often asked to enter valuable information on the number pad displayed on the touchscreen. Such valuable information includes the PIN numbers (e.g., requested by IP phone companies), social security numbers (e.g., requested by credit card companies or credit card centers), date of birth (e.g., requested by insurance companies). In the number logging attack, we apply TapLogger to log the user inputs on the number pad during the call. Specifically, in the training mode, the attacker first collects training data by HostApp with the layout of number pad (shown in Figure 3.7), and then builds a classifier for tap position inference. In the logging mode, the SensorListener monitors the readings of motion sensors and performs the task of tap event detection and tap position inference. Specifically, the Sen- sorListener will be invoked when the phone conversation starts (i.e., upon receiving CALL STATE OFFHOOK intent) and will be stopped when the phone conver- sation ends (i.e., upon receiving CALL STATE IDLE intent).

Figure 3.9. An example of tap position inference in the number pad logging attack 39

3.6.2.2 Tap Position Inference

In the number pad logging attack, we build the classifier by applying k-means clustering to the training data belonging to each label/button. Each label/button will be considered as one class. In the logging mode, given a tap event detected by the SensorListener service, we first extract features from the orientation sensor readings, and then measure the distances from this detected tap event to the trained clusters of all labels. Shorter distance means higher similarity to the cluster. As buttons are close to each other, solely taking the label with shortest distance may cause high inaccuracy. Therefore, in the number logging attack, TapLogger may output several top ranked candidate labels for each detected tap event. An example of inference is presented in Figure 3.9 for demonstration. In this example, the real inputs are 16 numbers entered on the number pad layout shown in Fig- ure 3.7. For each tap event, TapLogger outputs the top 4 candidate labels. The 1st label is the one with the closest distance in the k-means clustering. For example, for the first input “4”, the inferred labels are “1, 5, 4, 2” ranked by measured distances. The number pad layout shows that the mistakenly inferred labels “1”, “4”, and “2” are neighboring buttons around the real input “4”. If the attacker only take the top one or top two labels, the true label “4” will not be covered. As shown in the example, for the whole sequence of inputs, the coverage of true inputs with only the 1st label is 0.3125. The coverage will increase as more top ranked candidate labels are taken into consideration. In this example, the coverage of true inputs will increase to 1.0 when all the top 3 candidate labels are considered.

3.6.2.3 Evaluations

In the evaluation, we randomly generated 20 sequences of tap inputs with length of 16. Before the testing, the user is asked to play the HostApp for about 60 rounds to create the training dataset. We measure the coverage on each button in the number pad layout. The experiments results with different number of top ranked labels are listed in Figure 3.10. From the experimental results, several observations attract our attentions. First of all, from the observed coverage, it is easier to distinguish the buttons close to the edge (such as button “#”) than the inner buttons (such as button “5” and “8”). 40

Figure 3.10. Evaluation of number pad logging attack

Secondly, outputting more top ranked candidate labels can greatly increase the coverage of inference. For example, the average coverage with only the top 1 label is about 0.364, and the average coverage with the top 1&2&3&4 labels is about 0.887. Moreover, taking the top four labels would achieve high coverage rates on all buttons. This is reasonable because the mistakenly inferred labels are mostly neighboring labels of the truly tapped button. Based on these observations, the attacker may achieve a high coverage of the true inputs by slightly increasing the search space. 41

3.6.3 Password Stealing Attack

3.6.3.1 Attack Overview

Passwords (i.e., PINs) based screen lock is the most common way to protect the smartphone from being accessed by unauthorized users. Briefly, when the screen of smartphone is turned on, the user will be asked for entering a sequence of passwords (i.e., PIN numbers) to unlock the screen. Such a sequence of passwords usually consists of a sequence of number from 0 to 9. The length of passwords is 4 on iOS and 4 or more on Android platform. Stealing the password of screen lock provides the attacker the access to the victim smartphone as well as some private information carried by the password itself. For example, people would like to use the same passwords in different occasions. Before the attack, TapLogger first uses the HostApp with the layout shown in Figure 3.7 to collect the pattern of tap events and build the classifier for tap position classifier in the training mode. To log the screen lock passwords, the ContextIdentifier starts the SensorLis- tener service when the screen is turned on (i.e., upon receiving an intent of AC- TION SCREEN ON ) and stops the SensorListener after a certain period of time (e.g., 10 seconds). Because the user will be asked to enter the passwords whenever the screen is turned on. During this period of time, if tap events are detected, the ContextIdentifier will use the built-in classifier to infer the tap position and further the related button that has been pressed.

3.6.3.2 Tap Position Inference

To improve the accuracy of inference, we utilize one observation: suppose that the password of screen lock does not change and the user always enters passwords correctly, the user will always enter the same passwords in every round. With this observation, TapLogger divides the passwords into a sequence of individual inputs. Each input corresponds to the tap event at a fixed position of this sequence. TapLogger builds an Inference Distribution Table for each input in this sequence. For example, in Figure 3.11, the user enters the same passwords “5, 7, 6, 0” for 32 rounds. In each round, the first input is always the same. Thus, for every tap event detected as the first input, TapLogger will add one to its inferred label in 42 the table, meaning that the tap event in this round is inferred as this label. In this way, the inference distribution table counts the number of times that a certain label (i.e., button) was inferred as a user input. The more frequently a label is inferred, the more likely this label is the real user input. Note that, if the sample size is small, the true input may not be top ranked in the distribution. As shown in Figure 3.11, the top ranked label with input # 4 is button Del instead of button 0 (the real input).

Figure 3.11. Example of inference distribution table

Thus, TapLogger may output several top ranked labels for each input instead of only the toppest one. We name them Top-1 Inference, Top-2 Inference, and Top-3 Inference, representing the number of top ranked label in the inference distribution table. In Figure 3.11, we show these three types of outputs on the right side. Correspondingly, the coverage of an inference is defined as the number of inputs that appear in the inferred labels. In the case of Figure 3.11, the Top-1 Coverage is 3/4 = 75%, while the Top-2 Coverage and Top-3 Coverage are both 100%. Obviously, Top-3 Inference always generates better coverage rate than Top-1 Inference. However, it also means a greater search space for identifying the exact 43

Table 3.3. The results of screen lock attack

Password Length 4 6 8 Average Top-1 Coverage 0.4 0.266 0.45 Average Top-2 Coverage 0.75 0.6002 0.925 Average Top-3 Coverage 1.0 0.8 0.975

true input by the attacker. With the Top-3 Inference of a password of length 4, the search space for the attacker to try is 34 = 81, but the search space of a Top-2 Inference is only 24 = 16.

3.6.3.3 Evaluations

Experiments have been done with randomly generated passwords of length 4, 6, and 8. Five passwords are generated for each length. Before the attack, the user is asked to play the HostApp for about 60 rounds to build the training dataset. To collect the testing dataset, the user is asked to enter each password 30 rounds with TapLogger working in the logging mode. For tap position inference, we build the classifier using LibSVM [61]. The results of average coverage in our experiments is shown in Table 3.3. Ac- cording to the experimental results, with TapLogger, the attacker may only need to try the top 3 labels for each input and receive a high probability of hitting the actual password. Note that, in the Table 3.3, the average coverage with password length 8 is even better than that of length 6. This is because some randomly gen- erated passwords of length 6 contain inner buttons, e.g., Button 5, which causes a low coverage rate.

3.7 Discussion

3.7.1 Security Permission Requirements

Note that, as motion sensors are considered as an insensitive resource, TapLogger does not require any security permission to access the accelerometer and orientation sensors. In fact, accessing both sensors on other platforms, such as iOS and 44

Blackberry OS, do not require security permission either. Moreover, as the ContextIdentifier service keeps running in the background, the reader may wonder if a curious user may find it suspicious when reviewing the list of running services in Service Manager. First of all, we admit that the ContextIdentifier service will appear in the list of running services. However, as the smartphone platform and apps are becoming more and more complex, there are usually tens of services, e.g., system’s or apps’, running in the background. According to our experience on the PC, the attacker can easily fool the user by giving the ContextIdentifier service a “benign” name to avoid being noticed.

3.7.2 Overhead Analysis

Computational Overhead: the computational overhead of TapLogger on smart- phone includes detecting tap events with a MonitorW in of sensor readings and training a classifier for tap position inference. The workload of tap event detection is low because the size of MonitorW in is fixed and limited (e.g.,< 50 readings). Suppose a sensor reading is represented by 4 Bytes. Only 200 Bytes are required in the memory. Also, our tap event detection algorithm relies on heuristic rules and is very lightweight. For the classifier, both LibSVM and K-means approaches are applied in our at- tacks. As only six features are applied in the inference, the computational overhead is small. During the experiments, training a classifier with LibSVM with about 800 tap events takes seconds to complete. Thus, the computational overhead is not a problem for TapLogger. Another concern is about the battery consumption caused by continuous sens- ing with the accelerometer and orientation sensors. According to our measurements on Nexus, the battery can only hold for less than 4 hours if we keep sensing with accelerometer sensors as the highest sample rate. To avoid draining the battery, our ContextIdentifier identifies the current context of smartphone and starts the sensing when the touchscreen is on. Therefore, when the touchscreen is off, the sensing will be stopped and TapLogger incurs no overhead at all. In this way, we avoid draining the battery by continuous sensing. Communication Overhead Analysis: TapLogger sends inferred sensitive user 45 inputs to a remote attack server with labels of zones of a target view. Thus, the generated traffic is very little. To avoid the user from noticing data uploading, TapLogger stealthily uploads in two ways. One way is to send the data when the user is interacting with the HostApp. For example, TapLogger may upload the collected tap events when the user is uploading his local scores to online game center. The other way is to transmits data in background after the touchscreen is turned off. This approach is more timely and the amount of each data transmission will be smaller. It is suggested uploading tap events collected in the logging mode using this approach.

3.7.3 Attack on Other Platforms

Other smartphones, such as iOS and BlackBerry OS, support similar on-board sensors equipped on devices. There are already thousands of iPhone and iPad apps that leverage the accelerometer sensor in gaming, healthcare areas, etc. Similar to the accelerometer usage defined on Android platform, iOS also provides three axes readings: X axis reading for moving left or right, Y axis reading for moving forward or backward, and Z axis reading for moving up or down. We can obtain them by implementing a class specifying the UIAccelerometerDelegate protocol to listen to the accelerometer events. Although iOS 4 does not support true multitasking (except a few services, e.g., streaming), which means our taplogger cannot reside in background running on iOS devices to keep tracking tap events, it is feasible doing on jailbreaked iOS devices. We do not discuss BlackBerry in this dissertation because touchscreen based BlackBerry devices are rare in the sense of both in BlackBerry family and in smartphone market share. However, our approach will be still valid with careful investigation of the working mechanism of the on-board sensors on BlackBerry.

3.7.4 Countermeasures

The fundamental problem here is that sensing is unmanaged on existing smart- phone platforms. People are still unaware of potential risks of unmanaged sensors on smartphones. To prevent such types of attacks, we see an urgent need for sens- ing management systems on the existing commodity smartphone platforms. For 46 example, we could modify the privacy mode introduced in [62] to place security restrictions on data access to onboard sensors. Sensors, such as accelerometer and orientation sensors, should all be considered as sensitive to user’s privacy and need gaining security permissions to access. Further, even with permission restrictions on the on-board sensors, the attacker may still be able to gain access to sensor readings indirectly, e.g., through the confused deputy attack [63] or the permission re-delegation attacke [64]. In this case, the defense approaches recently proposed in [64] and [65] could be applied on smartphones. Third, from the perspective of a user, several approaches can all increase the difficulties of attacks launched by TapLogger, such as changing the password fre- quently, choosing password with numbers difficult to infer, and increasing the length of PIN numbers. Chapter 4

A Privacy-Aware Sensor Management Framework for Smartphones

4.1 Overview of SemaDroid

With the studies of sensor-based mobile context inference [66, 67] and user activ- ity recognition [68, 67], recent studies on offensive techniques, including our work presented in Chapter 3, have shown prototypes of innovative sensor-based attacks on smartphones, including location tracking attacks (with GPS [49, 47] and ac- celerometer [52]), stealthy video capturing attack (with camera [50]), audio-based logging attack (with microphone [51]), vibration-based logging attack on keystrokes of nearby keyboards (with accelerometer [20]), vibration-based logging attack on user touchscreen inputs (with accelerometer and orientation sensors [22, 21, 24]). These merging sensor-based attacks expose the flaws and ineffectiveness of ex- isting permission-based sensor management systems. Different from traditional sensitive information, such as contact lists and system files, the sensitivity of sen- sor data depends on the context in which the data was collected and the quality of data (e.g., precision). Existing permission-based access control can only help decide if an app is allowed to access particular sensors. Once permissions are granted, the user has no knowledge or control over the sensor usage. For example, 48 the trojan app Soundcomber [51] first tricks the user to grant the permission for audio recording and then stealthily abuses the privilege to record the voice of a user during phone calls. Thus, simply introducing more permissions for onboard sensors will not help protect users from sensor-based attacks. In this chapter, we propose a privacy-aware sensor management framework, named SemaDroid, which extends the existing sensor management framework on Android to provide comprehensive and fine-grained access control over the sensor usage of installed third party apps. Compared to the existing sensor management system on Android, SemaDroid covers not only the permission-associated sensors, e.g., GPS and camera, but also sensors overlooked by the existing sensor manage- ment system, e.g., accelerometer, orientation, and proximity sensors. To monitor the sensor usage and enforce sensor usage policies, SemaDroid first introduces the notion of Quality-of-Sensing (QoSn) to measure the quality of sen- sor data provided by sensors to sensing apps. Based on this provider-consumer relation, SemaDroid allows the user to monitor the sensor usage of every installed third party app from the perspectives of (1) the context under which the sensor data is collected and (2) the QoSn of data that is collected from the onboard sen- sors. Then, SemaDroid allows the user to manage the sensor usage by specifying context-aware and QoSn-based sensor usage policies and enforcing the policies in real time. To balance the privacy and desired functionalities, SemaDroid provides a Pri- vacy Bargain feature, which allows the user to interactively refine the SemaDroid sensor usage policies based on the trade-off between privacy and desired function- alities. This is based on the observation that the content of sensor data collected may always contain more or less information about the user, and the user might be willing to bargain the QoSn of a sensor in exchange for relative rewards of desired functionalities. The trade-off is that the higher QoSn an app can obtain from a sensor, the more likely user information will be leaked. When the QoSn is too low, the desired functionalities may be affected. Moreover, SemaDroid provides a unique Mock Data Generator service that generates continuous mock sensor data for different types of sensors. The generated mock data simulate the real sensor readings collected from onboard sensors but contain no private information. When the content of collected sensor data does 49 not affect the desired functionalities of a sensing app, SemaDroid allows the user to feed the sensing app with mock data in order to keep the app running while not sacrificing user privacy. Currently, SemaDroid has been implemented on Android version 4.0.3. De- tailed framework design and implementation are presented to show that SemaDroid works compatible with the existing permission based access control system on An- droid. Evaluations and demonstrations will also be presented to show how Se- maDroid allows the user to manage onboard sensors and how to defeat existing sensor-based attacks with specified SemaDroid policies.

4.2 Related Works

Compared to the existing literatures, SemaDroid distinguishes itself from them by focusing on managing the sensor data collected from onboard sensors. As men- tioned in previous sections, sensors are different from traditional sensitive resources such as SMS and contact lists. Firstly, sensors provide continuous sensor data to the installed sensing app. Thus, SemaDroid considers a sensor as a service provider rather than a stored data file. Secondly, the traditional context-aware access con- trol policies may look fine-grained for traditional data files, but is not fine-grained enough for sensor data, especially because sensor data collection is context aware. Thus, we introduce sensor management policies not only on the permission to ac- cess a sensor but also on the quality of sensor data an app can get. Thirdly, existing mock data techniques do not suit sensor data. For example, Android provides a Mock Location provider function for testing purpose. It allows the app to create a mock location provider with a fixed location. However, as the mock location is fixed, apps relying on location updates will crash. The proposed Mock Data Generator service in SemaDroid that is able to provide continuous mock sensor data.

4.2.1 Access Control on Smartphones

Some literatures have been proposed to provide access control on smartphones. Few literatures mentioned sensor management because they did not realize the 50 differences between sensors and other types of resources (like contact list). [69] proposes a system, named MockDroid, that feeds third party applications with fixed fake values for location, phone identifiers, Internet connection status, intent broadcasts, SMS/MMS, calendar, and contacts. However, sensors with con- tinuous sensor data feeding are not mentioned. [70] proposes a system, named TISSA, that implements a privacy mode on An- droid. In the privacy mode, the user is allowed to specify the contents of location, phone identity, contacts, and call log for each third party application. Related to sensor data, TISSA only mentions supplying apps with anonymized or bogus lo- cation information, but no details is mentioned on how to generate anonymized or bogus location information or how to supply this information to apps while keeping them running properly. As explained in SemaDroid design, supplying continuous mock location requires approaches different from supplying a mock data file. [71] proposes a system, named AppFence, that allows users to withhold data from imperious applications by substituting real data with innocuous shadow data. Specifically, AppFence shadows browser metadata, SMS/MMS messages, subscribed feeds, contacts, accounts, and calendar entries by returning a set of predefined fake data. However, sensor data is not mentioned in AppFence. As explained, sensor data is different from the ordinary sensitive resources. AppFence cannot be applied in sensor management. Both Saint [72] and Apex [73] study extending the existing Android permis- sion system in order to support additional run-time permissions. However, firstly, sensors not covered by the existing Android permission system will not be cov- ered by Saint and Apex. Secondly, both works study the problem of granting the permissions basing on context. Differently, SemaDroid focuses on how to manage the sensor data (so as to protect user privacy) even if the access to the sensor is allowed.

4.2.2 Sensor Management on Smartphones

[74] introduces a privacy architecture, called Personal Data Vaults (PDVs), that provides the user the access control over the sensor data shared with content- service providers. Different from our approach, PDV provides the privacy control 51 on a server called PDVs. Sensing data are collected and uploaded to the PDVs server first, and the user then decides data sharing in PDVs. SemaDroid provides solutions on the smartphone directly. [75] focuses on the data usage side and presents a general-purpose policy language for usage control, called Obligation Specification Language (OSL), which may help one define the usage policy in the framework. Differently, we protect the user at the data collection side. [76] proposes a personalized ad delivery system in which users can decide how much information about their private context they are willing to share with the ad-server. More important, in this chapter, the authors formalized the privacy problem as an NP-hard problem and proposed optimization objective functions. This work is for individual sensing apps. That is, the app of this system is equipped with sensing management mechanism. We are proposing a framework for managing all apps and no sensor management mechanism is prerequisite. [77] discusses how to balance the issues of energy consumption, latency and accuracy for mobile sensing. The mentioned factors affecting mobile sensing are useful to describe our Quality-of-Sensing measures. Also, this chapter discusses the enforcement of QoS measures. TrustDroid [78] introduces a domain isolation approach that groups the apps and stored data by different trust levels. However, TustDroid focuses on preventing the untrusted apps from accessing trusted data, e.g. SMS and Calendar. No sensor is mentioned in this work.

4.3 Security Model

4.3.1 Attack Model

The attackers in our work are installed third party apps which attempt to collect sensor data when a user is not willing to share it. Such apps include (1) mal- ware (e.g., Trojan apps proposed in [22, 51]) that attempt to infer sensitive user information from collected sensor data; and (2) curious apps that attempt to im- prove their functionalities, e.g., collecting location information for ads targeting and news delivery [79]. As the third party apps have already been installed on the 52 smartphone, we assume that they have gained permissions to access the sensors they request. Also, we assume that all apps access the sensors via APIs specified in the standard Android sdk (Android 4.0.3 SDK [80]). Web applications running in mobile browsers may also be able to access onboard sensors (e.g., GPS) via APIs provided by mobile browsers. In this case, these web applications will be treated the same as the web browser.1

4.3.2 Trust Model

We assume that the Android OS is not compromised. The proposed SemaDroid is implemented within the Application Framework layout of Android OS. Hence, the security of SemaDroid is protected by the Android OS. SemaDroid only commu- nicates with components within the Android OS and none of its APIs is exposed to third party apps. As all third party apps are sandboxed in the Dalvik virtual machine, the third party apps have neither the knowledge about the existence of SemaDroid, nor the access to the APIs of SemaDroid.

4.4 SemaDroid Design

In this section, we present the design of SemaDroid, a sensor management frame- work that allows the user to track the sensor usage of installed apps and then control the sensor usage by enforcing user customized policies. In the design of SemaDroid, we focus on solving three challenges:

• How to monitor the sensor usage information? So that the user can monitor the sensor usage information of installed third party apps.

• How to specify and enforce the sensor usage policies on installed third party apps? So that the user can restrict the sensor usage of apps when in sensitive contexts. 1Currently, Android allows implementing web applications in two ways. One way is to make your web content in a traditional web browser. In this way, the web app will access sensor data (e.g., location) via web browser. As SemaDroid enforces policies basing on the uid of originating installed apps, the policies for this host web browser will be enforced. The other way is to build a separate app by including a WebView in it. In this case, SemaDroid can enforce policies on a specific web app according to its host app. 53

• How to balance the privacy and desired functionalities? So that the user can customize the sensor usage policies according to his preference on privacy protection and enjoying desired functionalities.

To answer these challenges, we first present an overview of SemaDroid and show how the SemaDroid can help the user to monitor the sensor usage information. In the Section 4.5, we elaborate the detailed design of sensor usage policy on installed apps. We will introduce a privacy bargain feature for balancing the privacy and desired functionalities in Section 4.6. The detailed implementation of SemaDroid on Android will be described in Section 4.7.

4.4.1 SemaDroid Framework Design

In Figure 4.1, we present an overview of sensor usage management in SemaDroid. Basically, SemaDroid consists of four components and a set of hooks (named Sema- Hook) embedded within the existing modules of Android. Next we briefly describe the functions of SemaDroid components.

Installed Apps SemaDroid Third Party Apps Portal App

Application Sensor Framework Monitor Sensor Management Sensor Policy Service Manager Sema Hook Mock Data Generator

Linux Kernel Sensor Driver

Figure 4.1. An overview sensor usage management in SemaDroid

Portal: The Portal app is a SemaDroid app located within the /system/app folder, like the default Contact and Settings apps of Android. It is implemented as a user interface app that allows the user to interact with the SemaDroid framework. 54

Through the Portal app, the user can view the sensor usage of all installed third party apps, create sensor usage policies, and enforce the policies in real-time. SensorMonitor: The SensorMonitor is implemented as a system service with APIs accessible only inside the Android OS or by the Portal app. SensorMonitor provides two services. First, SensorMonitor keeps tracking the sensor usage of every installed app so that the Portal app can retrieve the sensor usage information and show it to the user for review. Second, SensorMonitor is the interface for SemaHook to query for sensor usage policies. When receiving a policy query from a SemaHook, SensorMonitor will fetch the corresponding sensor usage policies from the SensorPolicyManager service, extract the enforcement rules from policies, and then return the rules to the requester SemaHook for enforcement. SensorPolicyManager: The SensorPolicyManager is also implemented as a system service with APIs accessible only by SensorMonitor and Portal. It main- tains all sensor usage policies and answers policy queries from SensorMonitor. Besides, together with the Portal, SensorPolicyManager allows the user to create and customize the sensor usage policies. MockSensorDataGenerator: The MockSensorDataGenerator is a featured service provided by SemaDroid. Briefly, it maintains a set of threads that gen- erate mock sensor data for different sensor types. SemaDroid allows the user to replace the real sensor data with mock data so as to keep the app running while not sacrificing his privacy. SemaHooks: SemaHooks are codes we place within the existing Android com- ponents. The major functions of SemaHooks include intercepting sensor access re- quests from apps, communicating with SensorMonitor service, and enforcing sensor usage policies during the sensor data collection.

4.4.2 SemaDroid Workflow

We briefly explain how SemaDroid works from two aspects. One is from the aspect of user interaction and the other is from the aspect of policy enforcement. 55

4.4.2.1 Allowing Sensor Usage Management

The smartphone user interacts with SemaDroid through the Portal app, which provides a sensor usage review function and a policy management function. With the sensor usage review function, the user can review a sensor usage report for every individual app. As demonstrated in Figure 4.2, a sensor usage report consists of sensor usage records on all accessed sensors. Each usage record is described by the starting time, usage duration, and a set of phone state descriptions within this duration. The phone state descriptions are used to describe the context of smartphone usage. The other function is the policy management function. The Portal app shows the existing SemaDroid policies associated with each installed app. Also, it allows the user to create new sensor usage policies and customize the existing sensor usage policies.

4.4.2.2 Enforcing Sensor Usage Policies

In SemaDroid, the policy enforcement workflow starts from the embedded Sema- Hook when a sensor access request is intercepted. Here, we briefly explain the common steps in the policy enforcement. Details about enforcement on different types of sensors will be presented in Section 4.7 Implementation. Step 1 Interception: When a sensor access request is intercepted, the SemaHook will send the requested sensor type with the requester app’s uid to the SensorMon- itor service, asking for rules to enforce. Step 2 Policy Retrieval: With the sensor type and uid, SensorMonitor retrieves a set of stored sensor usage policies from the SensorPolicyManager (if existing). Each sensor usage policy contains a description of its enforcement context, detailing the context under which this policy can be applied (as in Figure 4.3). SensorMon- itor will filter the retrieved policies with the current context, such as current time and phone states. With the policies applicable in the current context, SensorMon- itor retrieves the enforcement rules of the requested sensor type and returns them to SemaHook for enforcement. Step 3 Rule Enforcement: Those received enforcement rules contain the guid- ance about how this sensor data collection should be performed. SemaHook will then enforce the received enforcement rules during sensor data collection. 56

Figure 4.2. A demonstration of sensor usage report

Next we will describe how to specify the sensor usage policy in order to prevent leaking private sensor data to installed third party apps.

4.5 Usage Policy Design and Enforcement

SemaDroid allows the user to control the sensing apps by placing fine-grained policies on their sensor usage instead of simply following the privileges of sensor access. A sensor usage policy in SemaDroid describes in what context sensor data 57 collection can be performed and the best quality of sensor data that is allowed to collect. For example, an informal example sensor usage policy may state “app A is allowed to collect sensor data from accelerometer, between 1:00 am and 8:00 am, with sample rate no greater than 20 Hz”. In SemaDroid, a sensor usage policy consists of three sections: Policy Property, Enforcement Context, and Quality-of-Sensing(QoSn) based Enforcement Rules.A policy file is organized in standard XML format as shown in Figure 4.3.

Figure 4.3. An example of SemaDroid policy

4.5.1 Policy Design

The Policy Property section includes the information about the app under man- agement and the modification information about the policy.

4.5.1.1 app-info Section

A sensor usage policy supports one or multiple apps. One app is represented by an app-info section in the XML file. Each app is identified by its package identification, 58 such as app:package=“xxx.yyy.zzz”. When the SensorPolicyManager service loads the policy, it will contact the PackageManager and get the uid corresponding to the package name. Policy enforcement is based on uid instead of package name. This is because multiple apps on Android can share the same uid by setting the sharedUid value and the same signature. In this case, all apps with the same uid can share resources with one another. Thus, SemaDroid enforces policies by uid. Moreover, SemaDroid supports two special app package names. One is denoted by “***.***.app” and named all-app, which represents all third party apps (i.e., all apps with uid greater than 10000 [81]). The other is denoted by “***.***.root” and named all-root, which represents all uids including system apps. These two special package names allow the user to specify policies effective for all apps on the smartphone.

4.5.1.2 policy-info Section

The policy-info section keeps the version information of the policy. Currently, SemaDroid supports two ways to create a policy. One is through the SemaDroid Portal system app (i.e. “ThroughPortal”),and the other approach is to load a policy file from the sd card (i.e., “ThroughSdcard”). When loading a file from sdcard, if the xml file name exists, SemaDroid will replace the existing policy file by the new one and update the subsection of “policy-info” accordingly.

4.5.2 Policy Enforcement Context

The Enforcement Context section specifies the context restrictions for policy en- forcement. The policy can be applied if and only if all restrictions described in the Context sections are satisfied. Currently, SemaDroid supports the following restrictions: Temporal Duration restriction describes the effective time interval. Options supported include the exact effective datea and expiration date (startdate and enddate), the repeated starting time and end time in a day (repeatstarttime and repeatendtime), etc. Phone State restriction is tagged by “phonestate”. Currently, SemaDroid sup- ports the set of telephone states maintained by TelephonyManager [80]. For ex- 59

Table 4.1. Enforcement rules supported by SemaDroid on different sensors (variables in () are parameters)

Sensor Types Enforcement Targets Type in Rules Method in Rules On Parameters (Delay) Rate Set, Times, AllowedRange; AdjustSampleRate Times; Unrestricted On Collected Sensor Data ( a AdjustTimeInterval Set, Times; Sensors SensorEvent consists of accuracy, Manipulate FilterWithFixed, FilterWithRan- timestamp, values[]) dom, Times, Set, Round; Mock Random, TraceFile; On Parameters ( minTime, minDis- minTime, minDistance, Set, AllowedRange; tance, criteria, etc.) criteria, etc. AdjustSampleRate Times; GPS On Collected Sensor Data (A AdjustTimeInterval Set, Times; Location consists of latitude, Manipulate FilterWithFixed,FilterWithRandom, longitude, etc.) Set, Round; Mock Random, TraceFile; On Parameters (output file, picture output file, picture size, Set, AllowedRange; Camera size, flash mode, etc.) flash mode, etc. (picture) On Collected Sensor Data (A Manipulate WaterMark, FilterWith- picture is represented by a byte[]) Fixed,FilterWithRandom, Set; Mock Random, TraceFile; On Parameters (output file, output output file, output format, Set; Microphone format, audio encorder, etc.) audio encorder, etc. (Audio On Collected Sensor Data (A frame Manipulate FilterWithFixed,FilterWithRandom, Recording) is represented by a Buffer object) Set; Mock Random, TraceFile; Microphone On Parameters (output file, video output file, video size, Set; and Camera size, video frame rate, etc.) video frame rate, etc. (Video On Collected Sensor Data (On the Manipulate Cut Recording) output file directly) Mock Empty, TraceFile;

ample, CALL STATE IDLE describes that the user is not making phone calls. SemaDroid determines the current telephone state by querying the system service Context.TELEPHONY SERVICE of Android. Usage State restriction is determined by monitoring the Intent broadcasted by Android. Currently, we heuristically select several typical states according to the attacks we attempt to defeat. One example is the SCREEN ON state which states that the screen is turned on. App State restriction describes the running status of sensing apps. SemaDroid determines the running status of an app, either foreground or background, by contacting the ActivityManager for the RunningAppProcessInfo of app. These stated restrictions help make context-aware sensor usage policies. For ex- ample, the policy of forbidding any third party app from accessing the microphone when the user is on the call can help easily defeat the attacks which stealthily record audio during phone calls; the policy of lowering the sample rate of motion sensors when the screen is turned on help defeat the attacks that infer user inputs when tapping on the touchscreen. Note that, location-based restrictions are not currently supported in SemaDroid because checking the current location whenever a policy query arrives will cause 60 a significant delay. While keeping tracking the location information will lower the delay, it is costly in battery consumption.

4.5.3 Quality-of-Sensing based Enforcement Rules

The QoSn-based Enforcement Rules allow the user to manage the sensor usage of a sensing app by controlling the quality of sensor data supplied to this app. When no enforcement rule is applied, the sensing app will always get the sensor data with finest QoSn (a.k.a., Original QoSn), which is determined by hardware specification, the sensor driver, and the version of Android OS. By enforcing the rules, SemaDroid allows the user to lower the QoSn by ad- justing sensing parameters, manipulating sensor data, and even supplying mock data. For example, in Figure 4.3, the enforcement rule on accelerometer states that, the real sample rate of accelerometer will be 0.5 times of the original sample rate specified by the sensing app. The enforcement rule on magnetic filed sensor states that the first reading in the value[] of collected SensorEvent will be round to a multiple of 0.1. The round-off errors from the raw reading are intentionally introduced to lower the QoSn of sensing service provided by the onboard magnetic file sensor.

4.5.4 Policy Enforcement

Sensor usage policies are enforced by SemaHooks through either the sensing pa- rameters or the collected sensor data. Through Parameters: Android allows the sensing app to guide the sensor data collection by specifying sensing parameters, such as the sample rate for accelerom- eter and the image size for camera. These specified parameters will be intercepted by SemaHook with the sensing request. SemaDroid allows the user to specify enforcement rules to manipulate the values of original parameters, such as the sample rate in Figure 4.3. Adjusting sensing parameters is the simplest approach to control the QoSn. Through Collected Sensor Data: when the sensor data collected by the Sensor Driver arrives at the Application Framework layer, the SemaHook will intercept the sensor data and enforce sensor usage policies before forwarding it to the sensing 61 app. For example, in Figure 4.3, the enforcement rules on magnetic field sensor is enforced on collected sensor data. The details about how to specify suitable QoSn based enforcement rules are presented in the next Section 4.6.

4.6 Privacy Bargain

User privacy has been defined in many ways in different research fields. In the context of phone sensing, sensors act as service providers supplying user’s personal (context) information to sensing apps. Thus, we adopt the definition of user privacy that is widely accepted in personal information privacy studies: user privacy is the ability of an individual to control the access others have to his/her personal information [82]. The control of user’s privacy refers to the ability to decide the amount and depth of information collected through the sensor data collection procedure. In this section, we show how SemaDroid can allow the user to bargain over their personal information in exchange of desired functions of sensing apps.

4.6.1 Definition of Privacy Bargain

Privacy Bargain is a concept where the users are willing to trade-off privacy for desired functions or to bargain the release of personal information in exchange of relatively small rewards [83, 84, 85]. Privacy bargain has been widely studied in the individual decision process with respect to user information privacy [83] and user online information privacy [84, 85]. During sensor data collection, the readings collected from onboard sensors con- tain user’s personal information as these readings are measured by examining the surrounding context of smartphones. For example, readings collected from motion sensors are widely used to infer the type of user activities [68, 67]. Thus, in our case, privacy bargain stands for the case when the user releases sensing information to sensing apps in return for desired functions of sensing apps. Foremost, the privacy bargain feature provide the flexibility of setting the Se- maDroid policies. For example, when the user is not certain about specifying 62 proper sensor usage policies for an installed app, he might start with a less re- stricted policy. And then he can use the privacy bargain feature of SemaDroid to add more restrictions until finding a most restricted policy that still not affects the desired functionalities.

4.6.2 Bargain Procedure using SemaDroid

SemaDroid provides the privacy bargain capacity by allowing the user to adjust the QoSn of sensing data collected. Given a sequence of sensor readings (i.e., the sensor data) collected in a time period, the amount of private information it contains depends on the QoSn this sensor provided during sensor data collection. For example, the higher sampling rate or the higher precision the readings are, the better QoSn this sensor can provide, thus the more private information this collected sensing data may carry. The whole privacy bargain process can be briefly summarized in the following steps:

1. the user reviews the sensor usage report of a sensing app via the Portal app;

2. according to the user’s preference and privacy concerns, the user may select the used sensors, and adjust their QoSn provided to this sensing app by creating and enforcing SemaDroid sensor usage policies on these sensors;

3. after enforcing the specified policies for a period of time, the user may adjust the enforcement rules in policies according to his using experience. Eventu- ally, the user will find the balance between the functionalities he/she desires and the QoSn he/she is willing to provide.

Admittedly, lower the QoSn (e.g., providing vague or mock sensor data) might affect some functionalities of sensing apps. However, from the perspective of users, if the functionalities are not desired, such as location based ads, feeding vague or mock sensing data would not be a problem as long as their desired functionalities, e.g., game control, are not affected. 63

4.6.3 QoSn Adjustment using SemaDroid

To adjust the QoSn, SemaDroid supports three types of enforcement rules: Data Adjustment Rules, Data Manipulation Rules, and Mock Data Rules. All rules are enforced by SemaHooks. The differences are the operations supported on the collected sensor data.

4.6.3.1 Data Adjustment Rules

Data Adjustment Rules do not alter the content of collected sensor data. Typical Data Adjustment Rules include adjusting the sample rate, adjusting the time inter- val between sensor data sampling, and dropping selected sensor readings according to predefined criteria. Data Adjustment Rules are suitable in cases when the user is conservative in providing sensing data, but the correctness of reported sensor events is critical to the desired functions in the sensing app. In these cases, the user would lower the QoSn but still provide accurate sensor data. For example, the user may adjust the sample rate of GPS in an example monitoring app to avoid aggressive location tracking.

4.6.3.2 Data Manipulation Rules

Data Manipulation Rules allow the user to manipulate the content of collected sensor data or adding noise. Typical Data Manipulation Rules include rounding the values in the sensor data to approximate values, replacing particular sensor readings by mock readings, manipulating the content of sensor events (e.g., adding watermarks to images taken by the camera), and adding noise (e.g.,adding mock readings). The mock readings are either generated randomly according to the specifications of rules, or loaded from sensor events previously recorded in a trace file. Data Manipulation Rules are suitable in cases when the user is suspicious of sensor data abuse in certain sensing apps. For example, to avoid inferring sensi- tive tap events on the touchscreen from collected motion sensor readings in the TapLogger attack [22], the user could intentionally add noise to readings reported by the accelerometer and orientation sensor. 64

4.6.3.3 Mock Data Rules

Mock Data Rules allow the user to completely replace the collected sensor data by mock data. This option enables the user to prohibit particular apps from getting any real context information, while keeping the app running. For example, many apps require sensor data from GPS for the embedded advertisement function [79, 86]. If the user is not interested in the content of advertisement, SemaDroid allows the user to provide mock GPS information to the app.

4.6.3.4 Rules Refinement

The Privacy Bargain function allows the user to refine their specified enforcement rules. Briefly, the user may keep reducing the QoSn starting from the Data Adjust- ment Rules until the Mock Data Rules. If feeding the sensing apps with the current enforcement rules causes little or even no side effect to the desired functions, the user can safely lower the QoSn. In this way, SemaDroid allows the user to enjoy the desired functionalities without sacrificing his/her privacy.

4.7 Implementation of SemaDroid

In this section, we present the detailed implementation of SemaDroid on Android (version 4.0.3). An overview of implementation is presented in Figure 4.4. A summary of all currently supported enforcement rules are listed in Table 4.1 for reference. Besides, as to SemaDroid itself, we focus on the Mock Data Gener- ator service whose details have not been discussed. Selected demonstrations are presented in Section 4.8 to show the capacity of SemaDroid on sensor management.

4.7.1 Unrestricted Sensors

In Android, SensorManager is a system service that allows sensing apps to access all unrestricted onboard sensors, including the accelerometer, ambient tempera- ture sensor, gravity sensor, gyroscope, ambient light sensor, magnetic field sensor, orientation sensor, atmosphere pressure sensor, proximity sensor, relative humid- ity sensor, and temperature sensor [80]. All sensors governed by SensorManager require no security permission to access and can be accessed by apps running in 65

Figure 4.4. The design of SemaDroid framework on Android the background. In Figure 4.5, we show how SemaDroid enforces sensor usage policies on these unrestricted sensors.

4.7.1.1 Normal Sensor Data Collection

To access a sensor, the sensing app will first prepare a class SensorEventListener for receiving the sensor events2, and then register the listener to the SensorManager by calling the function registerListener(). Within SensorManager, a ListenerDelegate thread will be created and associated to the SensorThread that keeps monitoring the SensorEventQueue by calling sensors data poll. When a sensor event is polled from the SensorEventQueue, the SensorThread will report the sensor event to all ListenerDelegate threads that care about it. A ListenerDelegate then forwards the received sensor event to the SensorEventListener within the sensing app. During the collection, the sensing app is only allowed to send a sample rate option with the registration request. This sample rate option is one of the following:

• SENSOR DELAY FASTEST, the fastest sample rate.

• SENSOR DELAY GAME, the 2nd fastest sample rate.

2The sensing app may also specify a Handler for sensor events 66

Figure 4.5. Enforcing sensor usage policies on sensors managed by SensorManager with SemaDroid

• SENSOR DELAY UI, the 3rd fastest sample rate.

• SENSOR DELAY NORMAL, the slowest sample rate.

Within the SensorManager, the sample rate option is converted into different de- lays between two sampling actions, e.g., SENSOR DELAY NORMAL is converted into 200000ns in Android 4.0.3 3. A sensor event collected from sensor driver is a vector of values

< accuracy, sensor type, timestamp, values[] >.

3Note that, this (recommend) delay will be sent to the sensor driver; but, the actual sample rate is ultimately determined by the sensor driver. Thus, the real sampling delay on the device might not be the recommended value. 67

4.7.1.2 Policy Enforcement with SemaDroid

SemaDroid intercepts the sensor request by the SemaHook placed in SensorMan- ager. When a sensor request is intercepted, the SemaHook will send the requested sensor type and the uid of requester app to the SensorMonitor service, which retrieves sensor usage policies from SensorPolicyManager and returns the enforce- ment rules applicable in the current context to the SemaHook. The enforcement rules can be applied either by the SemaHook in SensorMan- ager on the sampling delay, or by the SemaHook in ListenerDelegate on the col- lected raw sensor events. We list the supported enforcement rules in Table 4.1.

4.7.2 GPS and Network Location Providers

We present the implementation of SemaDroid with GPS as shown in Figure 4.6.

Figure 4.6. Enforcing SemaDroid Policies on GPS managed by LocationManager on Android 68

4.7.2.1 Normal Sensor Data Collection

In Android, the source of location information is called Location Provider. By default, Android supports three types of providers which are GPS that determines locations using satellites, Network that determines locations using cell tower and WiFi access points, and Passive that passively monitors location updates reported by other providers. SemaDroid covers all types of providers and we take GPS as the default location provider in our discussion. Specifically, Android allows installed third party apps to access the location information by two approaches through the LocationManager system service. One approach is to register an update listener, such as LocationListener or Broadcas- tReciver (updates sent out by providers as Intents), which obtains periodic updates of the smartphone’s geographical locations from the location provider. The sensing app can specify a set of parameters (e.g., a criteria) with the registration request to guide the sampling of location updates. The other approach is to get the last known location stored by the LocationManagerService. In this case, no actual sampling on GPS will be needed. As shown in Figure 4.6, the request for location information is actually ful- filled by the LocationManagerService. Unlike the unrestricted sensors, the GPS in Android is associated with security permissions,e.g., ACCESS FINE LOCATION. Thus, a permission check will be performed before starting sampling. A location update collected is a Location object, containing location information including latitude, longitude, timestamp, altitude, etc. When an update is received by the LocationManagerService, it will be forwarded to the listener of the sensing app and be used to renew the last known location record.

4.7.2.2 Policy Enforcement with SemaDroid

Similar to that with SensorManager, SemaDroid places one SemaHook right after the permission check to intercept the location request from sensing apps, and get the enforcement rules from the SensorMonitor. According to the content, the received rules will be either enforced locally on the parameters with the request, or be enforced by the other two SemaHooks on the collected location updates (i.e., the sensor data). 69

Note that, some system services provide a location tagging option. For example, when taking images from the camera, the app is allowed to add geographic location tag into the image taken. In this case, the location request will not go through the LocationManager, but it will still be handled by LocationManagerService. Thus, the location tagging service is also under the management of SemaDroid policies.

4.7.3 Camera

Camera in Android provides two functions, taking pictures and recording video clips. Both functions allow the sensing app to specify a output file location for the sensor data collected from camera, i.e., pictures and video clips. Android also supports a preview function that allows the app running on the screen to display a preview window of camera. However, this sensing app does not have access to the data in the preview window as the display and the data received in the preview window is controlled by Android OS. Thus, SemaDroid focus on the case when the collected sensor data is saved into designated files.

4.7.3.1 Normal Sensor Data Collection

Android supports two approaches to take pictures by a sensing app. One approach is by directly calling the function Camera.takePicture(), as illustrated in Figure 4.7. A PictureCallback function has to be specified in the sensing app to handle the collected picture. The other approach is by using other camera services (e.g., that of the Camera system app of Android) to take pictures. In this case, the sensing app has to specify the onActivityResult function for pictures returned through Intents. With both approaches, the picture taking request will be handled by Cam- eraService which assigns a Client to perform the sensor data collection and return the collected data (i.e., pictures) to the sensing app.

4.7.3.2 Policy Enforcement

SemaDroid places a SemaHook right after the permission check (i.e. the CAMERA permission) in the CameraService so as to intercept the request and enforce the sensor usage policies on the parameters specified by the sensing app. When the 70

Figure 4.7. Enforcing SemaDroid policies on Camera when taking pictures

Client receives the picture (as an array of data), the SemaHook in the Client will enforce the policies on the collected image, if policies exist. As Android provides many Java libraries for image processing, a SemaHook is also placed in the Camera in order to support enforcement rules with complex image processing functions.

4.7.4 Microphone

Android allows the sensing app to record audio data from the microphone to a designated output file. To the sensing app, the microphone is accessed by creating a MediaRecorder object and specifying its parameters. Inside Android, the sensing request will be handled by the AudioFlinger service which creates a RecordThread for sensor data collection.

4.7.4.1 Normal Sensor Data Collection

Specifically, the audio data is sampled frame by frame and each frame consists of an array of values, as illustrated in Figure 4.8. 71

Figure 4.8. Enforcing SemaDroid Policies on microphone

4.7.4.2 Policy Enforcement

As shown in Figure 4.7, SemaDroid places a SemaHook right after the AUDIO permission check in the AudioFlinger for policies enforced through parameters. When the RecordThread is assigned to this sensing request, the enforcement rules on collected sensor data will be passed to the SemaHook in the RecordThread.

4.7.5 Media Recorder

4.7.5.1 Normal Sensor Data Collection

Similar to picture taking, the sensing app records video clips either through the MediaRecorder or the Intent (i.e., requesting the video recording service provided by other apps). Inside Android, the recording request is handled by the Medi- aRecorderClient. The video recording workflow is shown in Figure 4.9 72

Figure 4.9. Enforcing SemaDroid Policies on camera and microphone when recording video clips

4.7.5.2 Policy Enforcement

Thus, SemaDroid places a SemaHook right after the permission check in the Medi- aRecorderClient for policies enforced on parameters. Different from picture taking, MediaRecorderClient relies on the underlying libraries to perform the recording task. Briefly, within the libraries, a buffer will be created for the frames captured from camera. Data in the buffer will be streamed to the designated output file di- rectly. Thus, for enforcement rules on collected sensor data, the SemaHook in the MediaRecorderClient will enforce the rules on the output file, not on the stream video data. 73

4.7.6 Mock Data Generator Service

In SemaDroid, the Mock Data Generator service maintains a set of worker threads that generate mock data values according to the specified sensor types and en- forcement rules. For every mock data request from SemaHook, the Mock Data Generator service assigns a separate worker thread. A worker thread ends when being notified by the requester SemaHook. For example, when the sensing app unregisters a listener for the GPS, the worker thread serving it will be ended. Note that, to lower the workload of a worker thread and improve the scalability, the worker thread only generates a sequence of values used for policy enforcement instead of (complete) sensor events. For example, if the enforcement rule is to generate mock longitude and latitude for GPS, the worker thread will generate a vector of only two values for a sensor event from GPS, instead of making an Android Location object. During enforcement, the SemaHook receiving this vector of values will then replace the longitude and latitude values of the genuine Location object received from GPS with the mock values. To the sensing app, the received location information will be mostly true except the longitude and latitude values. This design provides at least three benefits: first, it greatly lowers the workload of a worker thread; second, a worker thread can be reused on different types of sensors; third, as only values of concerns are mocked, it will be more difficult for the tricked sensing app to detect the mock data, for example, from the statistic of battery consumption. Note that, for testing purpose, Android provides a Mock Location provider function that allows the app to create a mock location provider, set one fixed mock location to the provider, and read this fixed mock location from it. This mock location provider does not generate continuous location updates. Moreover, for the app under test, it requires a security permission ACCESS MOCK LOCATION to create such a mock location provider. It also needs the cooperation from the user by turning on the mock location option in the settings of smartphone. 74

4.8 Application and Demonstration

4.8.1 Preventing Private Sensor Data Leakage

The Portal app of SemaDroid allows the smartphone user to review the sensor us- age reports of all installed apps. When suspicious sensor usages are detected, the user can create fine-grained sensor usage policies to place restrictions to the corre- sponding apps. Here, we select two sensor-based trojan attacks Soundcomber [51] and TapLogger [22] as examples to demonstrate the effectiveness of SemaDroid.

4.8.1.1 Sensor Usage Review

Suppose both trojan apps have been installed on the smartphone. We show how SemaDroid could help to defeat both attacks. Briefly, Soundcomber is a trojan app that stealthily records the voice of user during phone calls, and then extracts private information (e.g., credit card number) from the logged audio records. With SemaDroid, all the access to microphone sensor by Soundcomber will be logged. By reviewing the sensor usage reports, the user can see that the Soundcomber always accesses microphone during phone calls (i.e., “phonestate = OnCall”). TapLogger is a trojan app that stealthily monitors the motion changes of smart- phones so as to infer the password of screen lock and the numbers entered during a phone call (e.g., credit card). With SemaDroid, all the accesses to accelerometer and orientation sensor by TapLogger will be logged. By reviewing the sensor usage reports, the user may see that the TapLogger always accesses these two sensors in the background (i.e., “appstate = Background”), when the screen is on (i.e., “usagestate = ScreenOn”). If the attacks are performed during phone calls, the “phonestate” will also be “OnCall”.

4.8.1.2 Policy Design

With the suspicious access behavior detected, the user may determine to uninstall the corresponding sensing apps. However, suppose the suspicious access only hap- pens occasionally or the user is not certain about the suspicion. The user may still want to keep the suspicious app for desired functions. In this case, SemaDroid al- 75 lows the user to create sensor usage policies to place restrictions on those suspicious apps. Informally, we describe the corresponding policies as follows: • To defeat Soundcomber, the user may create a policy that “if the Sound- comber app tries to access from microphone when the phone state is OnCall and the app is running in the background, feed the Soundcomber app with mock audio data”.

• To defeat TapLogger, the user may create a policy that “if the TapLogger app tries to access the accelerometer and orientation sensor when the app is running in the background, lower its sample rate to 10 times of the original sample rate”. Moreover, even when no suspicious sensor usage is detected, the user may still specify preventative policies to prevent possible attacks, such as “App attempts to access microphone (or camera, GPS) will be supplied with mock sensor data.”.

4.8.2 Managing Sensor Usages

We present demonstrations to show the effectiveness of SemaDroid in managing accesses to onboard sensors. In Figure 4.10(a), we present a demonstration of sup- plying a location tracking app (My Tracks by Google) with mock location informa- tion. Briefly, in this experiment, we first use another app to record the location changes when a user excises in a park. the recorded trace of location changes will be used in SemaDroid as mock GPS data. Then, when sitting indoor, we launch the My Tracks app and supply the app with recorded GPS trace. This enforcement is performed with SemaDroid by specifying supplying mock data from the trace file in the sensor usage policy on My Tracks. As shown in the Figure 4.10(a), from the perspective of the My Tracks app, the smartphone (and the user) is moving in the park. In Figure 4.10(b), we present a demonstration of manipulating the sensor data collected from the microphone. The app in the experiment is the TapeMachine Lite Recorder, a popular audio recording app on Google’s app market. In the experiment, we create a sensor usage policy for this app that manipulates the col- lected audio sensor data by setting their values to 0. For comparison, we run both 76

the same TapeMachine Lite Recorder app on two Android phones that are placed together close to a speaker. One smartphone is equipped with SemaDroid and the other is not. In Figure 4.10(b), we show that, the left phone without SemaDroid can record the music played but the right phone with SemaDroid cannot. This is because SemaDroid blocks the audio input collected from microphone.

(1) Audio recording (2) Audio sensor data are manipulated without SemaDroid with SemaDroid (a) Supplying apps with mock (b) Supplying apps with mock audio data data GPS location information

Figure 4.10. Implementation of SemaDroid on Android

Further, in Figure 4.11(a), we present a demonstration of adding noise to sensor data collected from accelerometer (managed by SensorManager)4. By enforcing policies through SemaDroid, we show that the user may add noise to the data for any installed third party applications. Last but not the least, in Figure 4.11(b), we present a picture taken by the camera with content manipulated by SemaDroid according to the sensor usage policy. As illustrated in this demo, the application managed by this policy will

4The screenshot was taken by app Accelerometer Values 77 still work well as it can still receive picture data from the camera. However, much information of picture taken (i.e., the erased part) will not be accessible.

Two sets of noise readings added

(a) Demonstration of adding (b) Demonstration of sensor data ma- noise to sensor data collected nipulation on pictures collected from from accelerometer camera

Figure 4.11. Implementation of SemaDroid on Android

4.9 Discussions

4.9.1 Extending SemaDroid to iOS and BlackBerry OS

Sensor management has been ignored by not only Android but also iOS and Black- Berry OS. For example, accessing accelerometer and orientation sensor on both iOS and BlackBerry OS require no security permission. Also, existing sensor manage- ment systems on both iOS and BlackBerry OS rely on permission-based access control systems, not on sensor usage. Although iOS does not support multitask- ing thus preventing any stealthy sensor data collection by apps running in the background. Yet, it is still necessary to build a comprehensive sensor management framework like SemaDroid so as to protect the user’s private information, such as 78 location information, from the perspective of sensor usage. Further, the design of SemaDroid should apply to iOS and BlackBerry OS, especially the sensor usage policy design. The actual implementations on iOS and BlackBerry OS may vary due to the differences in operating systems.

4.9.2 Mock Sensor Data

In SemaDroid, mock sensor data is used to keep an app running while avoiding leaking the genuine sensor data. Preventing the consumer app from noticing the mock sensor data is not the focus of SemaDroid. However, with SemaDroid, the user has the full control over the content of sensor data given to the consumer app. Thus, we see the possibility that the user may intentionally not notify the app in order to gain benefits. For example, [87] presented an attack with fake location information in online social networks. [88] presented a discussion of using fake images in news reports. In community sensing applications, malicious users may use mock sensor data reported from their smartphones to launch pollution attacks against remote data collection. Another interesting question would be how to generate simulated mock data while preventing being detected by managed apps. For example, the values in the mock sensor data should not exceed the allowed ranges. Both the mock sensor generation and mock data detection would be interesting directions for our future research.

4.9.3 Coverage of SemaDroid

4.9.3.1 Sensor Coverage

For unrestricted sensors managed by SensorManager, all accesses must be through the SensorManager. Thus, by placing SemaHook within the SensorManager, Se- maDroid is able to govern all accesses to sensors managed by SensorManager. For other sensors, such as GPS, camera, and microphone, accessing these sensors require permission checks. Therefore, to guarantee the interception of sensor ac- cesses, we place a SemaHook right after every occurrence of the corresponding permission check. For example, accessing camera requires permission CAMERA. By examining the source code of Android, the permission check with CAMERA 79 only occurs twice. One is in the CameraService for image capturing, and the other is in the MediaRecorderClient for video recording. As such, SemaDroid places SemaHooks in both occurrences to guarantee the coverage of policy checking.

4.9.3.2 App Coverage

With the prevalence of sensor-based apps, most apps now require accesses to on- board sensors. However, it will be inconvenient for a smartphone user to examine every installed app and specify a sensor usage policy for each of them. To miti- gate this inconvenience, SemaDroid supports specifying policies for multiple apps or even all apps (with all-app package name) discussed in Section 4.5. For suspi- cious apps, SemaDroid supports the privacy bargain and allows the user to apply fine-grained sensor usage policies even with mock sensor data.

4.9.4 Malware Detection and Classification

As mentioned in Section 4.8.1, SemaDroid provides detailed sensor usage reports of installed apps and allows the user to discover the abnormal sensor usages from the report. Admittedly, our current abnormal detection approach is still based on heuristics and experience. However, we see the potential of developing new approaches for overprivilege detection [89] and malware classification.

4.9.5 Policy Design and Revocation

SemaDroid supports generic policies that are not specifically for known attacks. For example, the user can specify a policy that mutes the microphone for all apps (or selected apps) when entering a sensitive context. So, it is not necessary for the user to detect malicious apps first and then apply precise SemaDroid policies for them. By specifying generic policies, the user can place restrictions according to their demands. Meanwhile, a policy targeting at one app will not affect other apps that uses the same sensors. SemaDroid is able to identify the originating app of sensor data request, and enforces different policies on different apps when all of them are requesting the same sensor. 80

The policy revocation of SemaDroid depends on the types of policy. If the enforcement of policy is on the parameter of sensing task, then the revocation or update of policy will require restarting the sensing app. However, if the policy is enforced on the collected sensor data, it is possible to adjust the policy enforcement in real-time. For example, adjusting the quality of audio recording (e.g. sampling rate) will require restarting the app. However, if an app is already recording audio and it is possible for SemaDroid to mute the app by manipulating the audio data collected for it. All policies enforced by SemaDroid are stored in system space. Loading policy from SD card is only a feature that allows the user manually loads a policy file from SD card and display the policy on the SemaDroid Portal app. If the user likes the policy, he can save the content of policy (not the policy file from SD card directly) in system space. Therefore, the malware cannot temper the user defined policies stored in system space by manipulating the policy files stored on SD card.

4.9.6 Overhead Analysis

SemaDroid works compatible with the existing permission system with little over- head on Android. First of all, the three system services in SemaDroid are simple and single functioned. The MockDataGenerator service maintains a set of worker threads. But these worker threads are lightweight and can be reused, as discussed in the implementation section. Secondly, only the policy files will be loaded into memory. The mock data stored in trace files is loaded only when needed and cleaned when the worker thread ends. Thirdly, the delay caused by policy enforce- ment is usually neglectable with the SemaHook because most rules supported are simple operations.

4.9.7 Supporting New Types of Participatory Sensing

SemaDroid supports loading sensor usage policies (i.e., in XML form) from SD card. The sensing application developers and vendors are encouraged to publish recommended sensor usage policies for their apps, describing in what contexts their apps will perform the sensing tasks and how the sensor data collection will be per- formed. The recommended policies can help app vendors to promote their sensing 81 apps by mitigating the user’s concern of leaking private information by installing third-party apps. This is because with SemaDroid, one would only require down- loading third-party sensing policies instead of installing individual third-party sens- ing apps. On the user side, enforcing the recommended policies with SemaDroid guarantees that the sensing app will collect sensing data as claimed in its recom- mended policies. Of course, the user can make adjustments on the recommended policy via the SemaDroid Portal for customization. As such, with SemaDroid, many kinds of participatory sensing can be easily supported without installing third-party apps or changing the systems.

4.9.8 Limitation of SemaDroid on Android

To bypass SemaDroid, an approach would be receiving sensor data from other installed helper apps (with different uids) through side channels. In this case, the helper app may cause suspicion and may be blocked by sensor usage policies for the helper app. Furthermore, SemaDroid allows the user to prohibit all sensing tasks (including those performed by root privileges)5. However, some system features may be affected in this case, such as the automatic screen rotation feature.

5within the existing Android permission system, the access control on sensors (if exist) is based on the uid of requester thread. If a requester thread has root privilege, i.e., having a uid less or equal to 1000, the access to sensor will always be allowed without checking. SemaDroid identifies the originating app by the uid of requester thread. Thus, it is feasible for the user to create a policy that supplying even system apps/thread with manipulated sensor data. Chapter 5

Abusing Notification Services on Smartphones for Phishing and Spamming

5.1 Overview

Notification service is a system service provided by the smartphone platform to both system and third party applications. It allows a notification sender applica- tion to notify the smartphone user with a notification view when a trigger event happens. Common notifications include system update notifications, battery short- age notifications, and calender reminder notifications. In this chapter, we examine the notification service of four most popular smart- phone platforms [90], and investigate the feasibility for an installed trojan applica- tion to distribute phishing notifications or anonymous spam notification on these platforms. The selected smartphone platforms include Android (version 2.3 and 4.0), BlackBerry OS (version 7), iOS (version 5), and Windows Phone (version 7.1). According to comScore’s latest report [90], the selected four smartphone platforms cover 98% share of the U.S. smartphone market. Therefore, our results should have immediate impacts on the current smartphone market. We hope our proactive security study will draw attention of smartphone users as well as platform vendors. 83

5.2 Related Works

Phishing and spam attacks are two of the most successful and profitable at- tacks [91, 92]. Both attacks have achieved great success through traditional medias, such as email, web, and instant messaging. With the fast growth of smartphone markets, we have seen more and more attempts to launch phishing and spam at- tacks on popular smartphone platforms [93, 94, 95]. According to the statistical results in Trusteer report [96], smartphone users are more vulnerable to phishing and spam attacks due to the constrained UI on smartphones. However, most exist- ing phishing and spam attacks on smartphones still rely on traditional media, such as SMS [97], mobile email [96] and mobile web [94]. Studies are needed regard- ing launching phishing and spam attacks with new features provided by modern smartphone platforms.

5.2.1 Spam Attacks on Smartphones

Short Message Service (SMS) has been widely applied in distributing spam mes- sages to smartphone users. To defend the SMS spam attack, the user may report the sender number to the phone carriers [98], or rely on content based filtering applications, such as the Anti SMS Spam & Private Box for Android [99] and iBlackList for iOS [100]. Cormack et al. [101] suggested that new features are needed for SMS spam filters. Vura and Venter [93] proposed an artificial immune systems based approach to detect botnet spamming programs on Android phones. We also observed advertising Android apps, such as AirPush [102], which utilize the status bar notification to post third party advertisements on Android smartphones. Different from existing advertising apps that actively exposes their identity, our proposed trojan application hides its identity in the proposed spam notification attacks. Moreover, we show the feasibility of distribution spam notifications not only via status bar notification but also the toast notification service.

5.2.2 Phishing Attacks on Smartphone

Niu et al. [94] also studied the design flaws of mobile browsers that may allow web based phishing attacks. They pointed out that many featured functions of mobile 84 browsers, such as URL truncation and hiding URL bar on page load, may cause the difficulties for user to sense the phishing webpage. Besides Email and Browser, attempts of phishing attacks with fake applications have also been discovered. In the 09Droid case, a programmer named “09Droid” published several fake banking applications on Google’s Android Market trying to steal the user’s account login information. Also, Felt and Wagner [95] studied the feasibility of navigating the user to a fraudulent login view or login webpage by abusing the control transfer function provided on Android and iOS. One concern in their approach is the identity of trojan application is easy to reveal. For example, if the user is interacting with a malicious application before the transfer, the identity of this mobile application is known to the user. In our proposed phishing attacks, identify the trojan application will be much difficult for the smartphone user. Recently, Schulte and Percoco [103] presented a trojan based phishing attacks on Android, which claims to be able to exploit a design flaw of Android platform so as to lead the user to a fraudulent Facebook login view controlled by an installed trojan app. Google argued that such attacks are impractical [103] . Compared to the proposed view-based phishing attacks, the notification-based phishing attacks we proposed are more practical and easier to implement. Further, demonstrations of proposed phishing notification attacks on Android are presented as well.

5.3 Notification Customization

For notification customization, a sender application specifies a notification from three aspects: (1) the trigger event that will fire this notification, (2) the content to display in this notification, and (3) the allowed user operations on this notification. Trigger Event: The trigger event is an event that fires the notification. It could be a system event (e.g. scheduled alarms), or an application event generated by an application service running in the background. The flexibility on notification trig- gering allows a trojan application to fire anonymous notifications when it is not run- ning in the foreground. For example, on Android, a sender application can fire noti- fications whenever the screen is turned on with the Intent.ACTION SCREEN ON intent broadcasted by OS. 85

Figure 5.1. A comparison of OS-Controlled and App-Controlled notification views Notification View: The Notification View represents the displayed view of a notification. It carries the content that the sender application wants to show on the screen, such as a text message, an image, or even a complex subview. By the control of displayed contents, the notification views in existing notification services can be categorized into two groups, OS-Controlled and App-Controlled. In OS-Controlled notification views, the layout of a notification view is fixed and the sender application can only pass a text message to display. For example, in the Notification Alert on iOS 5 (shown in Figure 5.1(1)), the only thing that the sender application can control is the text message shown in the notification view. In App-Controlled notification views, a sender application is allowed to ma- nipulate the whole notification view, including the layout of view. Typical App- Controlled notification views include the Toast and Status Bar notification on Android, and the Dialog on BlackBerry OS 7. In Figure 5.1(2), we present a toast notification on Android with a single image in the notification view. Compared to the Figure 5.1(1), this customized toast notification hides the identity of sender ap- plication (i.e., “Notish”) and displays an unsolicited advertisement by customizing the notification view. Our proposed attacks rely on the App-Controlled notification views to send fraudulent phishing notifications and anonymous spam notifications without ex- posing the identity of a trojan application. Allowed User Operations: The allowed user operations include operations which the user can perform on the displayed notification, as well as the invoked actions of these operations. Due to the limited UI of smartphones, the allowed user 86 operations are usually restricted. One simple example of user operation would be: dismissing the notification when the notification view is tapped. More advanced actions include launching local applications (e.g., by firing an Intent on Android), opening the web browser with a specified URL address (e.g., by calling the web browser API on BlackBerry OS 7), and reopening the sender application (e.g., when a user clicks the View button on the notification alert on iOS 5). On Android and BlackBerry OS, a sender application can specify all the allowed user operations of a notification. To the opposite, on iOS, no customization is allowed on the allowed user operations. On Windows Phone, the sender application can only specify the view that will be navigated to. The control of allowed user operations is a prerequisite for the success of pro- posed phishing and spam notification attacks. In spam notification attacks, a trojan application specifies the allowed user operations to cover up its identity from being exposed to the user. In phishing notification attacks, besides hiding its identity, a trojan application navigates to the fraudulent views (e.g. a fake login view) when the user taps the notification view.

5.4 Phishing and Spam Notification Attacks

In this section, we study the feasibility of sending fraudulent phishing notifica- tions and anonymous spam notifications using an installed trojan application on a smartphone. Fraudulent notifications mimic the genuine notifications of target applications. Similar to adware, spam notifications contain unsolicited advertise- ments, such as commercial texts and images. To facilitate our discussion, we name our proposed trojan application Notish and its application icon is totally different from the Facebook application icon.

5.4.1 Phishing Notification Attack

In the phishing notification attack, the attack goal of Notish is to steal the user’s credentials for other installed applications, for example, the user’s account id and corresponding password of an installed mobile banking application. In our demon- strations, we take the Facebook application as our target application, and show 87 how to trick the user to enter her user id and password on a view controlled by Notish. Briefly, Notish first sends a fraudulent notification mimicking the notifications generated by the Facebook application. When the user taps on the fraudulent notification, she will be led to a fraudulent login view controlled by Notish. The fraudulent login view is a part of Notish, but it looks exactly the same as the login view of the Facebook application. The user id and the password entered on the fraudulent login view will be received by Notish. When the user clicks the login button, he will then be transferred to either the genuine Facebook application (e.g. on Android), or the genuine Facebook website (e.g. on BlackBerry). Meanwhile, the fraudulent login view, together with Notish, will terminate immediately after the transfer in order to hide Notish.

5.4.2 Spam Notification Attack

In the spam notification attack, the attack goal of Notish is to send spam notifi- cations while hiding its identity from the user. Briefly, Notish first sends a spam notification with unsolicited advertisements. When the user taps on the spam no- tification, this spam notification will dismiss and the user will be led to a spam website in the mobile browser. However, the spam notification attacks are also more perceptible in that the user will notice the posted unsolicited notifications. If the user can identify the sender application of spam notification, he may uninstall the trojan application and report the abuse to the app store. Although the trojan vendor may introduce new trojan applications after the exposure, the ephemeral trojan application will make the spam attack expensive. A detailed study of detecting notification attacks will be presented in Section 5.9. We elaborate the attack flow in 3 phases: plot → play → cleanup.

5.4.3 Plot

The plot phase happens when the trojan application is active, running either in the foreground or in background. In this phase, Notish specifies the details of the notification to be posted. 88

For trigger events, Notish may set the trigger event of notification at a time point when Notish is inactive or running in the background. For example, on An- droid, Notish may use the broadcasted Intent to trigger the notification whenever the screen is turned on; on BlackBerry OS 7, Notish can set a scheduled alarm to fire the notification at any time point suitable for Notish to hide itself. Phishing Attacks: To craft the fraudulent notification view, Notish will select the target application from installed applications on the current smartphone. To get the list of installed applications, it may use the P ackageManager API on An- droid and CodeModuleManager API on BlackBerry OS. According to the selected target application, Notish prepares the fraudulent notification view and the fraud- ulent login view. For the allowed user operations on the fraudulent notification view and login view, Notish has to mimic those operations provided by the target applications. Meanwhile, Notish has to make sure that the user will not be able to tell the identity of Notish based on the fraudulent notification and fraudulent login view. Spam Attacks: The unsolicited advertisements are predefined. Receiving spam contents from remote parties enables Notish to update the spam content as well as bypassing the application review process in the app store. The detailed benefits and design will be presented in Section 5.9. Also, Notish has to carefully specify all allowed user operations on this spam notification. For example, a conservative option would be dismissing the notification immediately no matter what operation the user will perform. A better option would be leading the user to a dedicated spam website after the user operates on the notification.

5.4.4 Play

When the specified trigger event occurs, the fraudulent phishing or spam notifica- tion will be displayed on the screen of smartphone. Phishing Attacks: After tapping on the notification, the fraudulent login view will be displayed asking the user to enter his user id and password to login. Ac- cording to [104], asking the user to enter user id and password is common for mobile banking and online social applications. Users will not be surprised about being asked to enter such information. 89

Notish may also navigate the user to a fraudulent login website in the browser instead of a fraudulent login view. This trick is popular in email phishing attacks and discussed in [94, 95]. However, fraudulent login view is more favorable when the target is an installed application. Fraudulent login website may cause suspicion. Spam Attacks: After tapping on the spam notification, the notification view will dismiss and the user might be led to a dedicated spam website in the mobile browser.

5.4.5 Cleanup

The major task in the cleanup phase is to erase traces of the phishing and spam notification attack so that the suspecting user will not be able to pinpoint Notish. In the cleanup phase, actions specified in the plot phase will be taken when user operations are received. For example, the displayed notification will be dismissed immediately; if the notification is fired by a background service of the trojan application, the service will be ended as well. Phishing Attacks: Note that, when the fraudulent login view is displayed, Notish will take the risk of being active and running in the foreground. Thus, cleanup works are needed for both the notification view and the fraudulent login view. A detailed analysis of attack detection will be presented in Section 5.9. Spam Attacks: Further, if Notish receives the spam contents from its application vendor, it will delete the received spam content as well in the clearnup phase.

5.5 Proposed Attacks on Android

Android is the dominant smartphone platform in the U.S. smartphone market with about 43.7% market share in 2011 Q2, according to [90]. In our study, we consider two releases of Android: Android 2.3 Gingerbread, the current major version, and Android 4.0 Ice Cream Sandwich, the latest version released in October 19, 2011. Both versions have a Toast notification, which is a type of Pop-up notification, and a Status Bar notification. The proposed phishing and spam notification attacks are successful on both versions of Android. As there is little change on the notification service from 90

Android 2.3 to Android 4.0, in this section we use Android 2.3 for demonstration.

Figure 5.2. Phishing and spam notification attack scenarios on Android 2.3

5.5.1 Attack with Toast

Android allows sending a toast notification with a default layout provided by An- droid, or with a customized layout provided by the sender application. The default layout only accepts text content and shows no authentication information. The customized layout is under fully control of sender application. As shown in Fig- ure 5.2(b), the trojan application can successfully send toast without exposing its identity within the notification view. Moreover, the toast notification does not accept user operations, and will be dismissed automatically after display. Thus, the annoyed user cannot identify the sender application based on the displayed toast notification. 91

5.5.2 Attack with Status Bar Notifications

On Android, the status bar notification service provides two types of notification views. One type of notification view is generated with the default layout. The other type of view is assigned directly by the sender application. With the default layout, the sender application is allowed to manipulate the application icon as well as the text content. As shown in Figure 5.2(b), Notish replaces its application icon with a Facebook icon in order to trick the user. With the view assigned by the sender application, the sender application can manipulate the notification view at will. In Figure 5.2(b), Notish displays a single image in the notification view. For status bar notification, a user is allowed to perform only two types of operations, one is “Clicking the notification”, and the other is clicking the “Clear all notifications” button on the screen, which will trigger Intent contentIntent and deleteIntent, respectively. The trojan application can specify the corresponding actions for these two Intents in the plot phase when creating the spam notification. For example, in our demo of Figure 5.2(b), when the user clicks on the notification, the spam notification will dismiss, and the default web browser will be launched with the URL of a spam website. As the notification view and all allowed user operations are under control of the trojan application, a user cannot identify the sender application from the displayed spam notification.

5.5.3 Attack Demonstration

Phishing Attacks: In Figure 5.2, we present the attack flow specifically on An- droid 2.3, and compare it with the work flow of the genuine Facebook application. The proposed attack uses status bar notification because it is also used by the gen- uine Facebook application on Android. As the Toast accepts no user operations, it cannot be used for phishing attacks. As shown in the Figure 5.2, by customizing the notification view, the trojan ap- plication can send a fraudulent notification view that is exactly the same as the real notification from the Facebook application. When the user taps on the fraudulent notification view, the fraudulent login view will be brought to foreground. The trojan application can launch the real Facebook application after receiving 92 the credentials. Many mobile applications keep the user’s session for a long period of time [104]. For example, as observed in [105], the Facebook app on Android will keep the session forever unless the user manually logout the app. If the ses- sion is not expired, when the trojan application launches the genuine Facebook application, the genuine Facebook application may navigate to the main menu directly (as shown in Figure 5.2). This will help further reduce the suspicion of phishing attacks. If the current session has expired, a new login view identical to the fraudulent login view will be shown by the genuine Facebook application. Seeing the new login view might cause little cause suspicion. However, as buttons on the touchscreen are close to each other, it is common for the user to enter wrong passwords by mistake and then be directed to the login view again. To sum up, three advanced characteristics of the view navigation mechanism on Android are the keys to the success of our phishing notification attack. Firstly, status bar notification view is customizable. Secondly, Android allows a user to be navigated to a specified view belonging to the sender application, such as the fraudulent login view. Thirdly, Android allows an installed application to launch another installed application. Spam Attacks: In Figure 5.2(b), we show the demonstrations of spam notification attacks launched by a trojan application. In all demonstrations, we trigger the notification 5 seconds after the screen is turned on using a background service.

5.6 Proposed Attacks on BlackBerry OS

BlackBerry OS is a popular smartphone platform that is famous for its customiz- able notification service. The BlackBerry OS 7 provides a Dialog service for pop-up notification, a Message List service for status bar notification, and an Icon Update service for icon notification. Here we show that it is feasible to launch phishing notification attacks with either the Dialog or the Message List.

5.6.1 Attack with Dialog

Dialog is a system service that pops up a predefined dialog on the screen and waits for user input. To trigger a notification, system events can be applied. For 93

REAL Message List Click A comparison of notifications displayed in the Message List

Fake

Click FAKE

Fraudulent REAL Message Mixed with real login view Box Facebook notifications The REAL Facebook website A comparison of notifications The trojan application steal the user’s is launched by trojan displayed in the Message Box credentials using a fraudulent login view application after stealing the credentials (a) Phishing notification attacks with Message List

REAL

A comparison of Facebook session expire dialog

FAKE

Fraudulent Fraudulent The REAL Facebook website is notification view login view launched by trojan application after stealing the credentials (b) Phishing notification attacks with Dialog

Figure 5.3. Phishing notification attack scenarios on BlackBerry OS 7 example, in our demo attack, Notish keeps a background service which auto-runs on startup. The background service uses a BackgroundClockListener to generate the trigger event at a time point specified by Notish. The notification view of Dialog is App-Controlled, which means Notish fully controls the contents of notification views. As shown in Figure 5.4, BlackBerry OS 7 allows filling the Dialog notification view with not only text content by its default layout, but also customized views (e.g., the fraudulent Facebook notification). Dialog provides richer notification views that allow buttons to be contained within the notification view. However, all user operations on the notification view of Dialog are under the control of a trojan application. Take the “OK” button in Figure 5.4 as an example, Notish can associate it with a button handling function. When the user presses the “OK” button, the Dialog will be closed and the default 94 web browser will be launched with the URL of a spam website. Furthermore, BlackBerry allows specifying responses even from the hard keyboard. In case the user presses any button in the hard keyboard, the Dialog will be closed and the spam website will be brought up in the browser.

5.6.2 Attack with Message List

Message List is a type of status bar notification service that only supports text based notifications. One unique feature of Message List is that, when a new no- tification is put into the status bar, a copy of notification messages may be saved within the Message Box. The same trigger events for Dialog notifications can also be applied to Message List notifications. The notification views in both the Message List and the Message Box are OS- Controlled with a fixed layout. However, the sender application is allowed to specify almost all the contents within the default layout. As shown in Figure 5.4, Notish can specify the image of indicator in Figure 5.4 (1), the subject and text content in Figure 5.4 (2.1), and the icon and text contents in Figure 5.4 (2.2). The only element that Notish cannot manipulate directly is the application icon shown in Figure 5.4 (2.1). To cover up the real application icon, the updateIcon function can be invoked by Notish to temporarily change its application icon to a fake icon, e.g., the Facebook icon shown in this demo. The risk of changing application icon is that, a skeptical user may check the application icons through the main menu to discover Notish. Thus, Notish must set an expiration time for the notification and erase it when expired. A safer way for Notish to prevent exposure would be marking the spam notifi- cation as read and save it into the Message Box directly. As only new notifications will be displayed within the Message List, the “read” spam notifications will appear in the Message List, thus Notish need not change its application icon. On the notification views of Message List, a user can tap both the messages and the application title bars. In both cases, the operations are under the control of Notish. The user will be navigated to the spam website in the spam notification attacks. On the notification views of Message Box, the platform provides a set of default 95

Click the OK button

OR

(1.1) A text spam (1.2) An image spam (3) the user will be led to a spam

notification using Dialog notification using Dialog k website in the mobile browser

c

i

l

k C c i l C Click Spam New Notification Noti. Indicator App Icon

Message Box Real Facebook notifications

Click

(1) The trojan application uses a (2.1) The spam notification shown in the (2.2) The spam notification also shown in fraudulent Facebook icon for the Message List the Message box spam notification (pretend to be a Facebook notification) (mimicking real Facebook notifications) Figure 5.4. Dialog and Message List based spam notification attack scenarios on Black- Berry OS 7 operations that are unrelated to the sender application. Also, the sender applica- tion can add customizable operations through the ApplicationMenuItem. Again, these customizable operations will delete the evidences of posted notifications and navigate the user to the spam website.

5.6.3 Attack Demonstration

We present the attack flow of both attacks in Figure 5.3 and 5.4. Phishing Attacks: As shown in the Figure 5.3, by customizing the notification view, Notish can easily fabricate the fraudulent notifications identical to the gen- uine Facebook notifications. By specifying the allowed user operations on both 96 views, Notish will navigate the user to a fraudulent login view of the trojan appli- cation. One flaw of the proposed phishing attack is that Notish can no more cover the attack by launching the genuine Facebook application as on Android, because launching another application from a third party application is not allowed on BlackBerry OS. To reduce the suspicion, Notish may navigate the user to the “pass- word incorrect webpage” of the genuine Facebook website(shown in Figure5.3). Spam Attacks: in Figure 5.4, we show the demos of spam notification attacks with both Dialog and Message List. Different to the phishing notification attack, the trojan application will navigate the user to a spam website instead of a fraud- ulent login view.

5.7 Proposed Attacks on iOS

With the newly introduced Notifications Center feature, iOS 5 has still been com- plained by application developers for placing restrictions on notification customiza- tion [106]. Briefly, the iOS 5 provides a pop-up notification service, called Alert, a status bar notification service, called Notification Center, and an icon notification service, called badge notification. Unlike other smartphone platforms, the user of iOS 5 decides how to display the notification on the screen. To send a notification, a third party application constructs an UILocalNotification object and passes it the iOS. Depending on user preference, the notification will be posted either as an alert dialog in the center of screen or as a banner on the top of screen. No matter which form the notification is displayed, it will be saved in the Notification Center that can be expanded at the top of screen. On iOS 5, the notification view in both the Alert and Notification Center are OS-Controlled. The sender application is only allowed to provided a short text message that will be displayed in the notification view with the sender application’s name and icon. We present the notification view of Alert and Notification Center in Figure 5.1 and Figure 5.5, respectively. As shown in both demos, the notification view of Alerts shows the name of the sender application, and the notification view of Notification Center displays both the name and the application icon of the 97

Figure 5.5. A spam notification shown in the Notification Center of iOS 5 (Notish is exposed in the notification view) sender application. Therefore, the spam notification attack fails because sending spam notification will expose the true identity of a trojan application. Neither the phishing notification attack nor the spam notification attack is feasible on iOS 5 because of the OS-Controlled notification views. The attempting trojan application will expose its true identity on the notification view. Further, even if the user is so careless by ignoring the displayed identity of the trojan application, the allowed user operations on the alert notification is under control of the iOS instead of the trojan application. For example, when a user taps on the View button in an Alert or a notification in the Notification Center, iOS will navigate to the last view of the trojan application or its starting view if it has been terminated. In either case, the phishing and spam notification attack will fail because there is no way to navigate the user to the designated view.

5.8 Proposed Attacks on Windows Phone

Similar to the iOS, the phishing and spam attack on Windows Phone OS 7.1 (abs. WP 7.1) also failed because the exposure of Notish on the notification view. WP 7.1 provides two types of notification services. One is a pop-up notification service, called Toast, which displays notification views on the top of screen; and the other is an icon notification service, called Tile, which displays notification view on the icon of a sender application. We investigate the feasibility of sending spam notification via the Toast service. On WP 7.1, the sender application is allowed to register a background agent, called Scheduled Task Agent, to the ScheduledActionService. This registered back- ground agent can be invoked by system events, such as time alert, when the sender application is inactive. Within the background agent, the sender application can specify a piece of code that will be executed when the agent is invoked. In our case, 98

Figure 5.6. A spam notification on Windows Phone 7.1 the sender application can fire a ShellToast notification on the screen, as shown in Figure 5.6. Similar to the notification center on iOS 5, the ShellToast is OS-Controlled and allows no customization on notification views. As shown in Figure 5.6, the application icon of the sender application (i.e., Notish app) will be shown in the notification view and the sender application can not interfere it. Different from iOS 5, WP 7.1 allows the sender application to specify a property NavigationUri of notification, with which the user will be transferred to a designated view of the sender application when he taps on the notification view. However, the OS- Controlled notification view of ShellToast will expose the identity of a spam sending application.

5.9 Discussion

5.9.1 Stealthiness of Trojan App

As described in Section 5.4, the trojan app carefully manipulates the posted no- tification in order to conceal its true identity from being discovered by smart- phone users. Besides, other attack-specific strategies can be applied to enhance the stealthiness of attacks. In the phishing notification attack, the trojan application mimics the target application (e.g., the Facebook application) so that the user will not realize being attacked. Another advantage for phishing notification attack is that, the number of target applications on one smartphone is very limited. To steal the user credentials of a target application, one successful attack would already be enough for the attacker. As the attack rate for phishing notification attack can be extremely low, the chance of exposing the attack and the trojan app will also be small. 99

In the spam notification attack, the smartphone user will certainly be aware of the unsolicited advertisements. As we described previously, the trojan applica- tion will dismiss the notification immediately after display so as to prevent being traced. On the side, one important observation is that, with the thriving of mo- bile app ecosystem, mobile app advertising has become popular and acceptable to smartphone users [107]. Based on this observation, two strategies may be adopted by the spam notification attacks. Firstly, the trojan app may lower the frequency of posting spam notifications. Secondly, the trojan app may take some other in- stalled mobile applications as scapegoat. For example, the trojan application may add the spam notifications with advertisements related an installed free game so as to mislead the annoyed user.

5.9.2 Stealthy Spam Content Distribution

To distribute and update the spam contents on smartphones, a straightforward way is to hard code the spam content within the trojan application. The trojan application vendor may update the hard coded spam contents with the application updates. This approach is simple and requires no further networking communica- tion between the trojan application and the trojan application vendor. However, the spam contents may be noticed by reviewers in the application review process of the application store [108]. Also, the update of spam contents can not be prompt. A better approach for spam content distribution and update would be sending the spam content separately from the trojan application vendor to the installed trojan application. Briefly, the trojan application vendor may send a “clean” ver- sion of a trojan application to the application store first. With the “clean” version, the trojan application could bypass the application review process easily. Once the trojan application is installed, the trojan application vendor then distributes spam contents through the network communication to the installed trojan application. A spam notification update may include the text and image to be displayed in the notification view, as well as the URL of a spam website that the user will be navigated to. Besides the common Internet connections, the push services may also be abused for the spam content distribution. 100

5.9.3 Push Service

Push service is a featured service that is gaining more and more popularity. It allows third-party application servers to actively send data to their installed appli- cations, even when the installed application is currently not running. To use the push service, the application vendor has to register at the service provider (e.g., Google and Apple). However, the push service provider has no knowledge about the contents distributed through the push service. The data distributed through the push service are messages that the vendor server wants to notify about. De- pending on the handling function defined in the installed application, the pushed data may or may not be displayed directly on the screen as notifications. Popular push services provided include the Android Cloud to Device Messaging Framework (C2DM) for Android [109], the BlackBerry Push Essentials and Push Plus for BlackBerry OS [110], the Apple Push Notification Service for iOS [111], and the Microsoft Push Notification Service for Windows Phone [112]. In the first two services on Android and BlackBerry, the pushed data are for general usage of data distribution. While, in the last two services on iOS and Windows Phone, the pushed data are specifically for notification and can be displayed directly through the local notification service. Due to the limit of space, we take the push service on Android as an example to demonstrate the application of push service in the proposed spam notification attacks. For Android, Google provides a C2DM infrastructure that allows the third party application to push a short message to the installed application. The payload of a message is up to 1024 bytes. The smartphone receiving the message will use Intent to awake and notify the receiver application. With the received message, the notified third party application can then synchronize with the server about the details. The handling function for the received short message in C2DM is defined and controlled by the installed application, and the receiver application decides whether or not to notify the user upon the received messages. In the proposed spam notification attacks with text spam contents, the 1024 bytes payload is already enough for the icon, text content, and the URL of spam websites. For spam notifications with image contents, the 1024 bytes restriction may limit the size of the image to display. Thus, the trojan application being notified may further synchronize with its vendor for details. 101

In the proposed phishing notification attacks, the C2DM service can also be applied to distribute the text and image data used in the fraudulent notification view and login view to the trojan application.

5.9.4 Incentives of Proposed Attacks

In the phishing notification attacks, the attacker may make profits by selling the phished account in the underground market [113] or abusing the phished account (e.g. PayPal and bank account) directly. With the increasing number of mobile finance apps, we believe the phishing attacks on mobile apps will gain more and more attentions to the attackers. In the spam notification attacks, the major revenue may come from the unso- licited advertisement. According to Gartner’s report [107], the worldwide mobile advertising revenue was about $1.6 billion in 2010 and about $3.3 billion in 2011. With the proposed spam notification attacks, the trojan application can make prof- its from distributing unsolicited advertisements that are not accepted by normal mobile advertising company, such as AdMob. Even when the trojan app is discovered, the loss to the trojan app developer is not significant. First of all, building a feature-rich and attractive mobile application has become easy. One quick approach to build a trojan application is to repackage existing legitimate mobile applications. As observed in [114], within the 68,187 apps the author collected from six third-party Android marketplaces, 5% to 13% apps are repackaged. Secondly, even the trojan app is reported and removed in the official market places, there exist many third party market places and app forums [115, 116] to distribute trojan applications. Those third party markets are not that managed as the official market places, and especially attractive to smartphone users looking for free piratical mobile applications. Thirdly, the cost of an account in the official application market places is trivial compared to the revenue gained in the proposed attacks (especially the phishing attacks). For example, on Android market place, there is only a one-time $25 registration fee for a developer account. 102

5.9.5 Jailbroken iOS

There exists a huge population of jailbroken iOS users [117, 118, 116]. One impor- tant feature with the jailbroken iOS is allowing customizable notification services. On jailbroken iOS 4 and iOS 5 [106], the sender application can manipulate the notification view, adding components, as well as taking control over the allowed user operations. Thus, both jail broken iOS 4 and iOS 5 are vulnerable to the proposed phishing and spam notification attacks. In addition, the iOS 5 Notification Center on iPhone includes a weather widget and a stock widget, which are able to display customizable views in the notification center. Although no other third party widgets are available so far, WillFour20 [119] presented a demo of building customizable widgets on jailbroken iOS 5 with only open APIs. We see the possibility of allowing customizable notifications and wid- gets on future iOS platforms.

5.9.6 Android 4.0

Android 4.0 also provides toast and status bar notifications. We have examined the source code related to toast and status bar notification in Android 4.0.3. According to our studies, there is little change on the notification service from Android 2.3 to Android 4.0. The proposed phishing and spam notification attack will work fine on Android 4.0 with exactly the same effectiveness as that on Android 2.3. For demonstrations, we present the proposed spam notification attacks on Android 4.0 in Figure 5.7. 103

(1) Toast with (2) Toast with text spam content image spam content Spam website

Click on the view

After clicking the notification view, the user (3) Status bar notification with (4) Status bar notification with will be led to a dedicated spam website. text spam content image spam content The spam notification view will be dismissed.

Figure 5.7. Demo of spam notification attack on Android 4.0 Chapter 6

Defending Notification based Attacks by View Authentication

Basing on the observations in the presented attacks, we propose defense mecha- nisms to mitigate these threats for both the smartphone platforms and the victim applications (e.g. the Facebook application). The implementation and demonstra- tions of proposed defense mechanisms are on Android because it is open source and is the most exploited smartphone platform.

6.1 Semi-OS-Controlled Notification

As shown in Figure 6.1, current smartphone platforms fall into two extremes on notification customization. On Android (left side), the most customizable smart- phone platform, a third party application is given the full control over the notifi- cation service. To the opposite (on the right side), on iOS, little customization is allowed. From the evolution of notification service, we have seen the trend of allowing customization in the notification service. However, from the proposed attacks, we see that the abuse of notification customization may enable a trojan application to launch phishing and spam notification attacks. New notification design is needed to allow notification customization while preventing the attacks. Thus, we propose a design principle for notification view design, named Semi- OS-Controlled notification view, which takes into consideration both customiza- 105

Figure 6.1. The App-Controlled notification view allows view customization but is lack of sender authentication information; The OS-Controlled notification view (e.g. iOS) is immune to proposed notification attacks but limits the capacity of app developers. The proposed Semi-OS-Controlled notification view supports view customization and is immune to notification attacks. tion and notification authentication. Briefly, as presented in Figure 6.1(2), a Semi-OS-Controlled notification view contains an OS-Controlled frame and a App- Controlled subview. Sender authentication information, such as application icon and application name, will be displayed within the frame. The sender application cannot modify the content in the OS-Controlled frame. But, the control of sub- view, together with the allowed operations on this subview, can be given to the sender application. For demonstration, we have updated the notification view from App-Controlled to Semi-OS-Controlled. Specifically, in our implementation, we modified the source code of Toast, Notification, and NotificationManager. Figure 6.2(a) presents an example when a third party application assigns a customized notification view to a status bar notification by setting Notification.contentView. Instead of posting the customized notification view directly, the modified NotificationManager will first retrieve the sender application identity from PackageManager, and build a frame view. The frame view wraps the received customized notification view as well as the sender application identity. In this way, the trojan application will expose its identity with the updated notification service. Further, our modification does not affect any existing APIs thus no update is required to existing third party applications. 106

6.2 Notification Logging Service

On all existing smartphone platforms, a displayed notification view will be dis- missed after the user operates on it. No notification logging service has been provided by the existing smartphone platforms. The Message Box on BlackBerry OS provides a simple logging service. However, the stored messages can be ma- nipulated and even deleted by a sender application.

6.2.1 Failure of Android EventLog

Android provides an EventLog service that allows a smartphone user to access the system diagnostic event records (certain system-level events). However, by observing the event records during the proposed toast and status bar based no- tification attacks, we found out that the EventLog service does not include any sender application information of toast and status bar notifications. After examining the source code of Toast, Notification, and NotificationService on Android OS, we see that, except for error messages, most logging functional- ities in these source codes only work in debug mode. For example, in the Noti- ficationService, most logging functions are called only in debug mode (i.e. when “DBG==true”); and in the Toast, all logging functions are called at a very low LOGV level. By default, these logs with LOGV are compiled out when the OS is built. Thus, in order to observe the information of sender application, the smart- phone user has to rebuild the Android OS from source code with debug mode enabled (e.g., by specifying the “-eng” option when building the OS [30]). With common Android smartphones sold in stores, common users will not be able to discover the sender information by observing the event log with Android SDK.

6.2.2 Proposed Notification Logging Service

Disappointed by the default EventLog service on Android and Message Box on BlackBerry OS, we propose a Notification Logging service in the smartphone plat- form. On Android, we implement the Notification Logging service as a Java writ- ten system service (named NotiLogService) running in the Application Framework layout. NotiLogService starts when the smartphone is turned on and maintains 107 a list of the latest toast and status bar notifications. The record of each piece of notification includes the triggering time and the sender application identity. For example, as shown in Figure 6.1, the NotificationManager will add an record in the NotiLogService service whenever a status bar notification is triggered. As the NotiLogService service is a system service, installed third party applications do not have access to the service. Thus, the NotiLogService service itself is secured. Currently, the user can access the NotiLogService through a dedicated UI app built with Android source code. In our future work, we are going to integrate this service into the “Settings” menu of Android.

6.3 SecureView Framework

The proposed phishing attack exposes an important vulnerability of lacking a view authentication service in the current view-based smartphone platforms. View is the basic UI of smartphone platforms. The application running in the foreground has control of the current view on the screen and accepts all user inputs on this view. However, on all current smartphone platforms, no view authentication information is displayed with the view, such as the identity of the foreground application. In the proposed phishing attacks, the trojan application could generate fraud- ulent login views mimicking login views of target applications. Due to the limited UI on smartphone, it is difficult for the user to sense the difference based on the fraudulent view. To protect the sensitive views, we propose a SecureView framework for a third party application to provide application authentication information on its sensitive views (e.g. login views). Specifically, using the SecureView framework, the user is allowed to choose a security image as well as writing a text-based security greeting after installing the application. Both the image and greeting are stored locally on the smartphone. This authentication information is associated with the current installation instead of the user account with this application. Whenever a sensitive view is displayed, the application can show the security image and greeting on the sensitive view to provide view authentication to the user. In Figure 6.2(b), we present a demo of the setup and application of SecureView. As all applications are isolated on Android, other installed (malicious) applications 108

(1) SecureView set up (2) View authentication (including an authentication image with SecureView and an authentication greeting ) (a) Implementation of Semi-OS-Controlled (b) The setup and application of Secure- notification view on Android View Figure 6.2. Proposed defense mechanisms

cannot record the SecureView displayed on the screen. The trust model for SecureView framework is that, there exists a secure storage for each application on the smartphone platform. This secure storage can only be accessed by its belonging application. Without subverting the platform, the trojan application cannot get knowledge about the security image and greeting, thus it cannot generate fraudulent sensitive views with valid view authentication information. This assumption is true for most existing smartphone platforms. One exception is the jail-broken iOS, in which a third party application has access to all the storage on the device.

6.4 Heuristic Approaches for Sender Application Identification

Admittedly, for security professionals, the trojan application may be identified in special environment with platform debugging tools. However, for normal users, the approaches on an off-the-shelf smartphones are limited. An intuitive approach would be examining all installed third party applications one by one. The user may uninstall a suspicious application and wait for a period of time. If no more spam notification or phishing notification is displayed, the uninstalled application would 109 probably be the trojan application. However, this approach is neither effective nor efficient. Because the trojan application may simply lower the attack frequency or even hibernate for a period of time to decrease its suspicion. Thus, disappearance of spam or phishing notifications cannot be easily used as a direct evidence for accusing a suspicious application. With the featured functions not related to notification services, some perse- verant users may try heuristic approaches to narrow down the list of suspicious applications. We discusses several heuristic approaches that the user could use on Android and BlackBerry OS.

6.4.1 Android

On Android, there exists a delay between the time that an application requests to end itself and the time that it is actually ended by the platform. Therefore, the trojan application may still be shown in the list of running applications for a period of time even it has requested to end itself immediately after firing the notification. Based on this observation, when the spam or phishing notification is displayed on the screen, the user may use the “Manage Apps” function provided by Android OS to check the list of running applications and services immediately. The “Man- age Apps” function is very similar to the well known Task Manager of Windows operating systems on PC. However, the delay is unpredictable depending on the Android OS. Further, the trojan application does not need to wait until the user sees the notification, and can stop immediately after firing the notification. The effectiveness of this heuris- tic approach is not guaranteed. Moreover, the list of running applications could be long, because allowing background services is a featured function on Android platform. Many third party applications keep background services, including news agent applications, online social network applications and music players.

6.4.2 BlackBerry OS

The BlackBerry OS provides a function called “Switch Application” that allows the user to switch among applications that are currently running. Based on our 110 experience through experiments, we note that the BlackBerry OS stops applica- tions faster than Android. However, when the spam or phishing notification is displayed on the screen, the user may check the listed running application. The trojan application would probably be within the list. However, the background service has been widely applied in third party applications on BlackBerry OS to keep monitoring the updates, such as news and email. Also, there is still no direct evidence to tell the trojan application from the list of running applications. Chapter 7

Conclusion and Future Works

7.1 Conclusion

The smartphone markets are becoming fiercely competitive. Smartphone vendors are eager to introduce new features to their smartphone platforms in order to attract the attention of smartphone consumers and third party application devel- opers. Those new features indeed promote new mobile applications (e.g., CNN iReport [120]), new business models (e.g., participating phone sensing [121]), and brings changes our lives (e.g. Google Wallet [11]). However, these new features also bring new challenges and vulnerabilities to smartphone platforms. Especially, as these features rarely appeared on traditional computer and dumbphones. The security and privacy issues related to such fea- tures are barely studied yet. Security approaches and mechanisms on existing smartphone platforms may not be able to solve these challenges and cover the vulnerabilities brought by new features. Meanwhile, the dramatic increase of malware in major smartphone platforms have shown a hint that smartphones are attracting more and more attention to professional attackers and sophisticated attacks. For example, the number of mal- ware discovered on Android increased by 700% in the year 2011, according the Threats Report: Second Quarter 2012 report by McAfee [122]. In the recent July 2012, a malware called “Find & Call”malware [123] targeting at iOS has been dis- covered in the Apple’s App Store which has been famous for its strict app review process. Clearly, neglecting the security concerns brought by new features would 112 cause great loss to both the smartphone user and the vendors in the future. In this dissertation, we have shown that, at least two popular features, onboard motion sensors and notification services, could be abused by installed trojan ap- plications to launch attacks. Furthermore, we introduce new defense approaches on current major smartphone platforms to defeat the proposed attacks. Specifically, we have shown our studies of the feasibility of inferring user inputs on smartphone touchscreen by monitoring readings collected from on-board motion sensors. A tap event detection scheme is presented to discover and utilize the user’s pattern with statistical measurements on acceleration, and then an approach of inferring tap position is presented with observed gesture changes. Further, we propose the detailed design of TapLogger, a trojan application implementing the proposed two approaches. We show two feasible attacks based on TapLogger and use experimental results to show the feasibility of proposed attacks. To protect users from onboard sensor based attacks, we propose SemaDroid, a privacy-aware sensor management framework for Android. SemaDroid provides a fine-grained and context-aware sensor management that allows the user to specify sensor usage policies by balancing the privacy and desired functions of apps with the privacy bargain function. Detailed design, implementation, and demonstra- tions are presented to show the capacity of SemaDroid in defeating sensor-based attacks on smartphones. About the notification service, we have shown our studies about the feasibility of launching phishing and spam attacks with an installed trojan application by abusing the customizable notification service. Experimental results and attack demonstrations are presented on four major smartphone platforms. Further, we present approaches for stealthy spam content distribution that can help the trojan applications bypass the application review process in application stores. To defend against the notification based attacks,we suggest a new Semi-OS- Controlled principle for notification view design, a SecureView framework for gen- eral view authentication, and a notification logging service for notification review. 113

7.2 Future Works

While vendors of major smartphone platforms are spending great efforts on pre- venting normal users from unlocking or gaining root privileges on their smart- phones, we believe that attacks basing on new features and the services they pro- vided are more promising and profitable to real world attackers. As the smartphone markets are continue to thrive, more and more new features will be introduced to smartphones. We will continue our studies on exploring innovative attacks basing on new features and then provide up-to-date security protections to smartphone users. Specifically, several directions are interesting to invest our efforts.

7.2.1 Onboard Sensor based Attacks

New types of sensors, such as NFC and fingerprint scanner, are being introduced to smartphones in order to promote new mobile applications. However, security studies should be performed before introducing new sensors. For example, Google is promoting their Google Wallet service using NFC sensor that has become a standard component on Android phones. Unfortunately, Charlie Miller recently show the attack technique that leverages NFC to direct the victim smartphone to a malicious Web site and then gain complete control of the smartphone [124]. In our future works,we will continue to explore attack approaches on major smartphone platforms with onboard sensors.

7.2.2 Sensor Management Approaches

The proposed SemaDroid framework has introduced a unique way of sensor man- agement different from the existing permission based access control system. Se- maDroid focuses on the sensor usage and enforces fine-grained policies basing on the current context of smartphones. Challenges remain including the efficient ways of context identification, protecting the SemaDroid framework from being detected or bypassed by malware applications, and automatic policy generation. Each of challenges mentioned worths separate studies. For example, to prevent be- ing detecting by installed malware applications, we are going to study the ways of 114 generating mock application running environment that mimics the real hardware device.

7.2.3 View Authentication on Smartphones

Current major smartphone platforms, such as iOS, Android, BlackBerry OS, and Windows Phones, are all view based. As we discussed in the notification based phishing and spam attacks, all interaction between the user and the smartphone is under control of the application whose view is displayed on the screen. Due to the restricted UI of smartphone, it would be more difficult for the user to figure out which application he is interacting with without view authentication information. Besides the proposed three defense approaches that provide view authentications, we are looking for more comprehensive approaches that not only covers notification views but also general views of smartphone systems during the daily usage.

7.2.4 Malware Detection

For advertisements and user studies, many benign mobile applications are also in- terested in collected user information from smartphones and even push unsolicited contents to the user. For example, the Facebook apps on Android requires accesses to all types of sensors including GPS and motions sensors. For malware detection purpose, we are going to build a developer reputation system and whitelist for renowned applications, such Facebook application. However, questions still re- main about how to identify and detect malware on smartphones. For example, if a whitelisted application keeps collecting sensor data in improper way/context, or keeps sending unwanted advertisements, does that makes this application a mal- ware? We believe this judgement could be subjective depending on the preference of users and the context of phone usage. in our future studies, we will continue to study the malicious behavior of malware and aim to build more accurate features that could be used to describe the malicious behaviors of third party applications on smartphone. Bibliography

[1] LUNDEN, I., “Gartner: Global Mobile Sales Down 2%, Smartphones Surge 43%, Apple Stalls As Fans Hold Out For New iPhone,” .

[2] Release, I. P., “Strong Demand for Smartphones in Second Quarter Con- tinues to Drive the Worldwide Mobile Phone Market, According to IDC,” http://www.idc.com/getdoc.jsp?containerId=prUS23624612.

[3] Wire, N., “Smartphones Account for Half of all Mobile Phones, Dom- inate New Phone Purchases in the US,” http://blog.nielsen.com/ nielsenwire/online_mobile/smartphones-account-for-half-of-all- mobile-phones-dominate-new-phone-purchases-in-the-us.

[4] Gartner, Inc., “Visualising the smartphone market change: Android leaps, Nokia wobbles.” http://www.guardian.co.uk/technology/blog/ 2010/nov/10/smartphone-market-growth-gartner-q3-2010.

[5] Google, “The Android official website,” http://www.android.com/.

[6] Apple Inc., “The iOS official website,” http://www.apple.com/ios/.

[7] Microsoft, “Windows Phone official website,” http://www.microsoft. com/windowsphone/en-us/default.aspx.

[8] Research In Motion, “BlackBerry OS official website,” http://us. blackberry.com/.

[9] Apple Inc., “iPhone official website,” http://www.apple.com/iphone/.

[10] Google Inc., “Nexus Galaxy,” http://www.google.com/nexus/#/ galaxy.

[11] Google, “Google Wallet,” http://www.google.com/wallet/. 116

[12] Wikipedia, “Comparison of smartphones,” http://en.wikipedia.org/ wiki/Comparison_of_smartphones.

[13] Electronic Arts, “Need for Speed Shift on iPhone,” http://itunes. apple.com/us/app/need-for-speed-shift/id337641298?mt=8.

[14] Ravindranath, L., C. Newport, H. Balakrishnan, and S. Madden (2011) “Improving wireless network performance using sensor hints,” in Pro- ceedings of USENIX conference on Networked systems design and implemen- tation.

[15] FitnessKeeper Inc., “RunKeeper application,” . URL runkeeper.com

[16] Apple, “shuffle songs on iPhone,” http://www.apple.com/iphone/ features/ipod.html.

[17] Android Developers, “SensorEvent specification,” http://developer. android.com/reference/android/hardware/SensorEvent.html.

[18] Apple iOS Developer Library, “UIAccelerometer Class Reference,” .

[19] BlackBerry, “UI and Navigation - Development Guide - BlackBerry Java SDK - 7.0 Beta,” .

[20] Marquardt, P., A. Verma, H. Carter, and P. Traynor (2011) “(sp)iPhone: decoding vibrations from nearby keyboards using mobile phone accelerometers,” in Proceedings of the 18th ACM conference on Computer and communications security, CCS ’11, ACM, pp. 551–562.

[21] Cai, L. and H. Chen (2011) “TouchLogger: Inferring Keystrokes On Touch Screen From Smartphone Motion,” in Proc. of HotSec’11.

[22] Xu, Z., K. Bai, and S. Zhu (2012) “TapLogger: inferring user inputs on smartphone touchscreens using on-board motion sensors,” in Proceedings of the fifth ACM conference on Security and Privacy in Wireless and Mobile Networks, WISEC ’12, ACM, New York, NY, USA, pp. 113–124. URL http://doi.acm.org/10.1145/2185448.2185465

[23] Miluzzo, E., A. Varshavsky, S. Balakrishnan, and R. R. Choud- hury (2012) “Tapprints: your finger taps have fingerprints,” in Proceedings of the 10th international conference on Mobile systems, applications, and services, MobiSys ’12, ACM, New York, NY, USA, pp. 323–336. URL http://doi.acm.org/10.1145/2307636.2307666 117

[24] Owusu, E., J. Han, S. Das, A. Perrig, and J. Zhang (2012) “ACCes- sory: Keystroke Inference using Accelerometers on Smartphones,” in Proc- ceedings of Workshop on Mobile Computing Systems and Applications (Hot- Mobile). [25] USA Today, “Hello, Big Brother: Digital sensors are watching us,” http://www.usatoday.com/tech/news/2011-01-26-digitalsensors26_ CV_N.htm. [26] Google Inc., “Android security and permissions,” http://developer. android.com/guide/topics/security/permissions.html. [27] Barrera, D., H. G. Kayacik, P. C. van Oorschot, and A. Somayaji (2010) “A methodology for empirical analysis of permission-based security models and its application to android,” in Proceedings of the 17th ACM conference on Computer and communications security, CCS ’10, ACM, New York, NY, USA, pp. 73–84. URL http://doi.acm.org/10.1145/1866307.1866317 [28] Android Open Source Project, “Android Security Overview,” http: //source.android.com/tech/security/index.html. [29] Apple Inc., “Cryptographic Services Guide: Encrypting Data,” http://developer.apple.com/library/mac/#documentation/ security/Conceptual/cryptoservices/GeneralPurposeCrypto/ GeneralPurposeCrypto.html. [30] Android, “The Android Open Source Project,” http://source.android. com/. [31] Motorola, “Writing Fingerprint-Enabled Apps,” http://developer. motorola.com/docs/writing-fingerprint-enabled-apps/. [32] Brut.alll, “Android-apktool: A tool for reverse engineering Android apk files,” . URL http://code.google.com/p/android-apktool/ [33] Lane, N. D., E. Miluzzo, H. Lu, D. Peebles, T. Choudhury, and A. T. Campbell (2010) “A survey of mobile phone sensing,” Comm. Mag., 48(9), pp. 140–150. URL http://dl.acm.org/citation.cfm?id=1866991.1867010 [34] Faulkner, M., M. Olson, R. Chandy, J. Krause, K. M. Chandy, and A. Krause (2011) “The Next Big One: Detecting Earthquakes and other Rare Events from Community-based Sensors,” in Proc. ACM/IEEE Inter- national Conference on Information Processing in Sensor Networks (IPSN). 118

[35] Android Developers, “Handling UI Events,” http://developer. android.com/guide/topics/ui/ui-events.html.

[36] Meier, R. (2009) Professional Android 2 Application Development, Wiley Publishing, Inc.

[37] Saffer, D. (2008) Designing Gestural Interfaces, O’Reilly.

[38] Wikipedia, “iOS jailbreaking,” http://en.wikipedia.org/wiki/IOS_ jailbreaking.

[39] Lineberry, A. (2010), “Android Touch-Event Hijacking,” http://blog. mylookout.com/2010/12/android-touch-event-hijacking/.

[40] Android Developers, “InputMethodManager,” http:// developer.android.com/reference/android/view/inputmethod/ InputMethodManager.html.

[41] Aviv, A. J., K. Gibson, E. Mossop, M. Blaze, and J. M. Smith (2010) “Smudge attacks on smartphone touch screens,” in Proceedings of the 4th USENIX conference on Offensive technologies, WOOT’10, pp. 1–7.

[42] Maggi, F., A. Volpatto, S. Gasparini, G. Boracchi, and S. Zanero (2011) “POSTER: Fast, Automatic iPhone Shoulder Surfing,” in Proc. of the 18th Conference on Computer and Communication Security (CCS).

[43] Raguram, R., A. M. White, D. Goswami, F. Monrose, and J.-M. Frahm (2011) “iSpy: automatic reconstruction of typed input from compro- mising reflections,” in Proceedings of the 18th ACM conference on Computer and communications security, CCS ’11, ACM, pp. 527–536.

[44] Lane, N. D., E. Miluzzo, H. Lu, D. Peebles, T. Choudhury, and A. T. Campbell (2010) “A survey of mobile phone sensing,” Comm. Mag., 48, pp. 140–150. URL http://portal.acm.org/citation.cfm?id=1866991.1867010

[45] Das, T., P. Mohan, V. N. Padmanabhan, R. Ramjee, and A. Sharma (2010) “PRISM: platform for remote sensing using smartphones,” in Proceed- ings of the international conf. on Mobile systems, applications, and services.

[46] Cai, L., S. Machiraju, and H. Chen (2009) “Defending against Sensor- Sniffing Attacks on Mobile Phones,” in The First ACM SIGCOMM Work- shop on Networking, Systems, Applications on Mobile Handhelds (Mobi- Held). 119

[47] Golle, P. and K. Partridge (2009) “On the Anonymity of Home/Work Location Pairs,” in Proceedings of the 7th International Conference on Per- vasive Computing, Pervasive ’09, Springer-Verlag, Berlin, Heidelberg, pp. 390–397. URL http://dx.doi.org/10.1007/978-3-642-01516-8_26 [48] Hoh, B., M. Gruteser, H. Xiong, and A. Alrabady (2006) “Enhanc- ing Security and Privacy in Traffic-Monitoring Systems,” IEEE Pervasive Computing, 5, pp. 38–46. URL http://portal.acm.org/citation.cfm?id=1175887.1176087 [49] Krumm, J. (2007) “Inference attacks on location tracks,” in Proceedings of the 5th international conference on Pervasive computing, PERVASIVE’07, Springer-Verlag, Berlin, Heidelberg, pp. 127–143. URL http://portal.acm.org/citation.cfm?id=1758156.1758167 [50] Xu, N., F. Zhang, Y. Luo, W. Jia, D. Xuan, and J. Teng (2009) “Stealthy video capturer: a new video-based spyware in 3G smartphones,” in Proceedings of the second ACM conference on Wireless network security. [51] Schlegel, R., K. Zhang, X. Zhou, M. Intwala, A. Kapadia, and X. Wang (2011) “Soundminer: A Stealthy and Context-Aware Sound Tro- jan for Smartphones,” in Proceedings of the 18th Annual Network and Dis- tributed System Security Symposium (NDSS). [52] Han, J., E. Owusu, T.-L. Nguyen, A. Perrig, and J. Zhang (2012) “ACComplice: Location Inference using Accelerometers on Smartphones,” in Proceedings of COMSNETS’12.

[53] Rovio Mobile Ltd., “Angry Birds on Android,” https://market. android.com/details?id=com.rovio.angrybirds. [54] Facebook Inc, “Facebook on Android,” https://market.android.com/ details?id=com.facebook.katana&hl=en. [55] Amazon LLC, “Kindle on Android,” https://market.android.com/ details?id=com.amazon.kindle. [56] Reddy, S., M. Mun, J. Burke, D. Estrin, M. Hansen, and M. Sri- vastava (2010) “Using mobile phones to determine transportation modes,” ACM Trans. Sen. Netw., 6, pp. 13:1–13:27. [57] Thiagarajan, A., J. Biagioni, T. Gerlich, and J. Eriksson (2010) “Cooperative transit tracking using smart-phones,” in Proceedings of the 8th ACM Conference on Embedded Networked Sensor Systems, SenSys ’10, pp. 85–98. 120

[58] Siewiorek, D., A. Smailagic, J. Furukawa, A. Krause, N. Moraveji, K. Reiger, J. Shaffer, and F. L. Wong (2003) “Sen- Say: A Context-Aware Mobile Phone,” in Proceedings of the 7th IEEE In- ternational Symposium on Wearable Computers, ISWC ’03, IEEE Computer Society, pp. 248–.

[59] Takeuchi, S., S. Tamura, and S. Hayamizu (2009) “Human Action Recognition Using Acceleration Information Based On Hidden Markov Model,” in Proc of 2009 APSIAPA Annual Summit and Conference.

[60] Ross, S. M. (1999) Introduction to Probability and Statistics for Engineers and Scientiests, 2nd ed., Academic Press.

[61] Chang, C.-C. and C.-J. Lin (2011) “LIBSVM: A library for support vector machines,” ACM Trans. Intell. Syst. Technol., 2, pp. 27:1–27:27.

[62] Zhou, Y., X. Zhang, X. Jiang, and V. W. Freeh “Taming Information- Stealing SmartphoneApplications (on Android),” in Proc. of TRUST’11.

[63] Hardy, N. (1988) “The Confused Deputy: (or why capabilities might have been invented),” SIGOPS Oper. Syst. Rev., 22, pp. 36–38.

[64] Felt, A. P., H. J. Wang, A. Moshchuk, S. Hanna, and E. Chin “Permission Re-Delegation: Attacks and Defenses,” in Proc. of Usenix Se- curity’11.

[65] Dietz, M., S. Shekhar, Y. Pisetsky, A. Shu, and D. S. Wallach (2011) “Quire: Lightweight Provenance for Smart Phone Operating Sys- tems,” in Proc. of Usenix Security’11.

[66] Lu, H., W. Pan, N. D. Lane, T. Choudhury, and A. T. Campbell (2009) “SoundSense: Scalable Sound Sensing for People-Centric Sensing Ap- plications on Mobile Phones,” in Proc. of7th ACM Conference on Mobile Systems, Applications, and Services (MobiSys ’09).

[67] Lu, H., A. B. Brush, B. Priyantha, A. Karlson, and J. Liu (2011) “SpeakerSense: Energy Efficient Unobtrusive Speaker Identification on Mo- bile Phones,” in Proceedings of the 9th International Conference on Pervasive Computing (Pervasive’11).

[68] Lane, N. D., Y. Xu, H. Lu, S. Hu, T. Choudhury, A. T. Camp- bell, and F. Zhao (2011) “Enabling Large-scale Human Activity Inference on Smartphones using Community Similarity Networks ( CSN ),” Pattern Recognition, pp. 355–364. URL http://dl.acm.org/citation.cfm?id=2030112.2030160 121

[69] Beresford, A., A. Rice, N. Skehin, and R. Sohan (2011) “MockDroid: Trading Privacy for Application Functionality on Smartphones,” in Proc. of the 12th Workshop on Mobile Computing Systems and Applications (HotMo- bile).

[70] Zhou, Y., X. Zhang, X. Jiang, and V. Freeh (2011) “Taming Information-Stealing Smartphone Applications (on Android),” in Proc. of the International Conference on Trust and Trustworthy Computing (TRUST).

[71] Hornyack, P., S. Han, J. Jung, S. Schechter, and D. Wetherall (2011) “These Arent the Droids Youre Looking For: Retrofitting Android to Protect Data from Imperious Applications,” in Proc. of the 18th ACM Conference on Computer and Communications Security (ACM CCS).

[72] Ongtang, M., S. McLaughlin, W. Enck, and P. McDaniel (2009) “Semantically Rich Application-Centric Security in Android,” in Proc. An- nual Computer Security Applications Conf. ACSAC ’09, pp. 340–349.

[73] Nauman, M., S. Khan, and X. Zhang (2010) “Apex: extending Android permission model and enforcement with user-defined runtime constraints,” in Proc. of ASIACCS ’10 Proceedings of the 5th ACM Symposium on Infor- mation, Computer and Communications Securit.

[74] Mun, M., S. Hao, N. Mishra, K. Shilton, J. Burke, D. Estrin, M. Hansen, and R. Govindan (2010) “Personal Data Vaults: A Locus of Control for Personal Data Streams,” in Proc. of ACM CoNEXT 2010.

[75] Hilty, M., A. Pretschner, D. Basin, C. Schaefer, and T. Wal- ter (2007) “A Policy Language for Distributed Usage Control,” in Proc. of ESORICS’07.

[76] Gotz, M. and S. Nath (2011) Privacy-Aware Personalization for Mobile Advertising, Tech. rep., MSR.

[77] Chu, D., N. D. Lane, T. T.-T. Lai, C. Pang, X. Meng, Q. Guo, F. Li, and F. Zhao (2011) “Balancing energy, latency and accuracy for mobile sensor data classification,” in Proceedings of the 9th ACM Conference on Embedded Networked Sensor Systems, SenSys ’11, ACM, New York, NY, USA, pp. 54–67. URL http://doi.acm.org/10.1145/2070942.2070949

[78] Bugiel, S., L. Davi, A. Dmitrienko, S. Heuser, A.-R. Sadeghi, and B. Shastry (2011) “Practical and lightweight domain isolation on An- droid,” in Proceedings of the 1st ACM workshop on Security and privacy in smartphones and mobile devices, SPSM ’11, ACM, New York, NY, USA, 122

pp. 51–62. URL http://doi.acm.org/10.1145/2046614.2046624 [79] Enck, W., D. Octeau, P. McDaniel, and S. Chaudhuri (2011) “A Study of Android Application Security,” in Proc. of Usenix Security’11.

[80] Google, “Android 4.0.3 Platform,” http://developer.android.com/ sdk/android-4.0.3.html. [81] Wiki, A., “Android UIDs and GIDs,” http://android-dls. com/wiki/index.php?title\unhbox\voidb@x\bgroup\let\unhbox\ voidb@x\setbox\@tempboxa\hbox{A\global\mathchardef\accent@ spacefactor\spacefactor}\accent22A\egroup\spacefactor\accent@ spacefactorndroid_UIDs_and_GIDs. [82] Culnan, M. J. (1993) “”How Did They Get My Name?”: An Exploratory Investigation of Consumer Attitudes toward Secondary Information Use,” MIS Quarterly, 17(3), pp. pp. 341–363. [83] Acquisti, A. and J. Grossklags (2004) “Privacy Attitudes and Privacy Behavior: Losses, Gains, and Hyperbolic Discounting,” Jean Camp and Stephen Lewis (Eds.) ”The Economics of Information Security”, pp. 165– 178. [84] Chellappa, R. K. and R. Sin (2002), “Personalization versus privacy: An empirical examination of the online consumers dilemma,” In 2002 Informs Meeting. [85] Hann, I.-H., K. L. Hui, S.-Y. T. Lee, and I. P. L. Png (2002) “On- line Information Privacy: Measuring the Cost-Benefit Trade-Off.” in ICIS (F. Miralles and J. Valor, eds.), Association for Information Systems, p. 1. [86] Hornyack, P., S. Han, J. Jung, S. Schechter, and D. Wetherall (2011) “These aren’t the droids you’re looking for: retrofitting android to protect data from imperious applications,” in Proceedings of the 18th ACM conference on Computer and communications security, CCS ’11, ACM, New York, NY, USA, pp. 639–652. URL http://doi.acm.org/10.1145/2046707.2046780 [87] Kincaid, J., “Foursquare Starts To Enforce The Rules, Cracks Down On Fake Check-Ins,” http://techcrunch.com/2010/04/07/foursquare- starts-to-enforce-the-rules-cracks-down-on-fake-check-ins/. [88] Laube, W. (2011), “Sickening tsunami of faked photos,” http: //www.smh.com.au/opinion/society-and-culture/sickening- tsunami-of-faked-photos-20110315-1bvuo.html. 123

[89] Felt, A. P., E. Chin, S. Hanna, D. Song, and D. Wagner (2011) “An- droid permissions demystified,” in Proceedings of the 18th ACM conference on Computer and communications security, CCS ’11, ACM, New York, NY, USA, pp. 627–638.

[90] Schroeder, S., “2 of every 3 Smartphones sold are Android or iOS,” http://mashable.com/2011/10/06/2-of-every-3-smartphones-sold- are-android-or-ios-report/.

[91] Kanich, C., C. Kreibich, K. Levchenko, B. Enright, G. Voelker, V. Paxson, and S. Savage (2009) “Spamalytics: An Empirical Analysis of Spam Marketing Conversion,” in Proc. of ACM CCS’09.

[92] Dhamija, R., J. D. Tygar, and M. Hearst (2006) “Why phishing works,” in Proc. of the SIGCHI conference on Human Factors in computing systems.

[93] Vural, I. and H. S. Venter (2011) “Detecting Mobile Spam Botnets Using Artificial immune Systems,” in IFIP Int. Conf. Digital Forensics, pp. 183–192.

[94] Niu, Y., F. Hsu, and H. Chen (2008) “iPhish: Phishing Vulnerabilities on Consumer Electronics,” in Proc. of UPSEC ’08.

[95] Adrienne Felt, D. W. (2011) “Phishing on Mobile Devices,” in Proc. of W2SP’11: WEB 2.0 Security and Privacy.

[96] Boodaei, M., “Mobile Users Three Times More Vulnerable to Phishing Attacks,” http://www.trusteer.com/blog/mobile-users-three-times- more-vulnerable-phishing-attacks.

[97] Wikipedia, “Mobile phone spam,” http://en.wikipedia.org/wiki/ Mobile_phone_spam.

[98] ATT, “Block spam text messages on your wireless phone,” http://www.att.com/esupport/article.jsp?sid=KB115812&cv=820# fbid=VLIsitNsUpI.

[99] Mate, D., “Anti SMS Spam & Private Box for Android,” https://play.google.com/store/apps/details?id=org.baole.app. antismsspam&hl=en.

[100] “iBlacklist for iPhone,” http://www.iblacklist.com.br/. 124

[101] Cormack, G. V., J. M. G. Hidalgo, and E. P. Sanz´ (2007) “Feature engineering for mobile (SMS) spam filtering,” in Proc. of ACM SIGIR con- ference on Research and development in information retrieval, SIGIR ’07, ACM, New York, NY, USA, pp. 871–872.

[102] airpush, “The Android Ad netowrk,” http://www.airpush.com/.

[103] Mills, E. (2011), “Android could allow mobile ad or phishing pop-ups,” http://news.cnet.com/.

[104] Jakobsson, M., E. Shi, P. Golle, and R. Chow (2009) “Implicit au- thentication for mobile devices,” in Proc. of HotSec Workshop ’09.

[105] Wright, G. (2012), “Facebook Plist Mobile Security Hole Al- lows Identity Theft,” http://garethwright.com/blog/facebook-mobile- security-hole-allows-identity-theft.

[106] Perez, S., “A New Reason to Jailbreak: Custom Widgets in iOS 5’s No- tifications Center,” http://developersarena.com/web/2011/06/a-new- reason-to-jailbreak-custom-widgets-in-ios-5s-notifications- center/.

[107] Gartner, Inc., “Gartner Says Worldwide Mobile Advertising Revenue Forecast to Reach 3.3 Billion in 2011,” http://www.gartner.com/it/page. jsp?id=1726614.

[108] Apple Inc., “App Store Review Guidelines,” https://developer.apple. com/appstore/guidelines.html.

[109] Google Developers, “Android Cloud to Device Messaging Framework,” http://code.google.com/android/c2dm/index.html.

[110] BlackBerry Developer, “BlackBerry Push Service Options,” http:// us.blackberry.com/developers/platform/pushapi.jsp.

[111] Apple Inc., “Apple Push Notification Service,” http://developer.apple. com/library/mac/documentation/NetworkingInternet/Conceptual/ RemoteNotificationsPG/ApplePushService/ApplePushService.html.

[112] Microsoft, “Push Notifications Overview for Windows Phone,” http:// msdn.microsoft.com/en-us/library/ff402558(v=vs.92).aspx.

[113] Krebsonsecurity, “How Much is That Phished PayPal Account?” http://krebsonsecurity.com/2011/10/how-much-is-that-phished- paypal-account/. 125

[114] Zhou, W., Y. Zhou, X. Jiang, and P. Ning (2011) “Detecting Repack- aged Smartphone Applications in Third-Party Android Marketplaces,” in Proc. of CODASPY’12.

[115] WeiPhone, “WeiPhone Forum,” bbs.weiphone.com.

[116] Freeman, J., “Cydia,” http://cydia.saurik.com/.

[117] Herrman, J., “iOS 4 Jailbroken Within a Day of First Release,” http://gizmodo.com/5558277/ios-4-jailbroken-within-a-day-of- first-release.

[118] Fish, E., “iOS 5 Jailbreak Is Already Here; Geeks Not Surprised,” http://www.pcworld.com/article/241877/ios_5_jailbreak_is_ already_here_geeks_not_surprised.html.

[119] WillFour20, “An example of a custom notification centre widget on iOS 5,” https://github.com/WillFour20/WeeAppTest.

[120] iReport, “CNN iReport,” http://www.ireport.com/.

[121] Yang, D., G. Xue, X. Fang, and J. Tang (2012) “Crowdsourcing to smartphones: incentive mechanism design for mobile phone sensing,” in Proc. of ACM International Conference on Mobile Computing and Network- ing (MobiCom’12).

[122] McAfee Labs (2012), “McAfee Threats Report: Second Quarter 2012,” http://www.mcafee.com/us/resources/reports/rp-quarterly- threat-q2-2012.pdf.

[123] Kingsley-Hughes, A. (2012), “First iOS malware hits App Store,” http://www.forbes.com/sites/adriankingsleyhughes/2012/07/06/ first-ios-malware-hits-app-store/.

[124] Goodin, D. (2012), “toppled by Near Field Communication hack,” http://arstechnica.com/security/2012/07/android-nokia- smartphone-hack/. Vita Zhi Xu

Zhi Xu enrolled in the Ph.D. program in Computer Science and Engineering at Pennsyl- vania State University in 2007. Prior to that, he received the M.S. degree in Computer Science from University of Ottawa in 2007 and the B.Eng. degree from Beijing Univer- sity of Aeronautics and Astronautics in 2004. His research interests include security and privacy issues in smartphones, phone sensing applications, and online social networks. Publications during the Ph.D. study include:

• Z. Xu and S. Zhu, “Abusing Notification Services on Smartphones for Phishing and Spamming”, in Proc. of the 6th USENIX Workshop on Offensive Technologies (WOOT), 2012.

• Z. Xu, H. Hsu, X. Chen, S. Zhu, and A. R. Hurson, “AK-PPM: An Authenticated Packet Attribution Scheme for Mobile Ad Hoc Networks”, in Proc. of the 15th Int. Symposium on Research in Attacks, Intrusions and Defenses (RAID), 2012.

• Z. Xu, K. Bai, and S. Zhu, “TapLogger: Inferring User Inputs on Smartphone Touchscreens Using On-board Motion Sensors”, in Proc. of the ACM Conf. on Security and Privacy in Wireless and Mobile Networks (WiSec), 2012.

• Z. Xu, K. Bai, S. Zhu, L. Liu, and R. Moulic, “Context-Related Access Control for Mobile Caching”, in Proc. of the Conf. on Security and Privacy in Communication Networks (SecureComm), 2011.

• A. Chaugule, Z. Xu, and S. Zhu, “A Specification Based Intrusion Detection Framework For Mobile Phones”, in Proc. of the Int. Conf. on Applied Cryp- tography and Network Security (ACNS), 2011.

• Z. Xu and S. Zhu, “Filtering Offensive Language in Online Communities using Grammatical Relations”, in the Proc. of Collaboration, Electronic messaging, Anti-Abuse and Spam Conf. (CEAS), 2010.

• B. Zhao, Z. Xu, C. Chi, S. Zhu, and G. Cao, “Mirroring Smartphones For Good: A Feasibility Study”, in Proc. of the Int. Conf. on Mobile and Ubiquitous Systems (MobiQuitous), 2010.

Awards during the Ph.D. study include:

• Student travel grants for conferences: WOOT’12, WiSec’12, and CEAS’10.

• Summer internships at Palo Alto Networks,CA (2012) and IBM T.J. Watson Re- search Center, NY (2010).

• Marie Underhill Noll Graduate Fellowship in Engineering, at Pennsylvania State University, 2007-2008.