Proceedings on Privacy Enhancing Technologies ; 2016 (3):96\u2013116
\nChad Spensky, Jeffrey Stewart, Arkady Yerukhimovich, Richard Shay, Ari Trachtenberg, Rick
\nHousley, and Robert K. Cunningham
\nSoK: Privacy on Mobile Devices \u2013 It\u2019s Complicated
\nAbstract: Modern mobile devices place a wide variety
\nof sensors and services within the personal space of their
\nusers. As a result, these devices are capable of transparently monitoring many sensitive aspects of these users\u2019
\nlives (e.g., location, health, or correspondences). Users
\ntypically trade access to this data for convenient applications and features, in many cases without a full appreciation of the nature and extent of the information that
\nthey are exposing to a variety of third parties. Nevertheless, studies show that users remain concerned about
\ntheir privacy and vendors have similarly been increasing their utilization of privacy-preserving technologies
\nin these devices. Still, despite significant efforts, these
\ntechnologies continue to fail in fundamental ways, leaving users\u2019 private data exposed.
\nIn this work, we survey the numerous components of
\nmobile devices, giving particular attention to those that
\ncollect, process, or protect users\u2019 private data. Whereas
\nthe individual components have been generally well
\nstudied and understood, examining the entire mobile device ecosystem provides significant insights into its overwhelming complexity. The numerous components of this
\ncomplex ecosystem are frequently built and controlled
\nby different parties with varying interests and incentives. Moreover, most of these parties are unknown to
\nthe typical user. The technologies that are employed to
\nprotect the users\u2019 privacy typically only do so within
\na small slice of this ecosystem, abstracting away the
\ngreater complexity of the system. Our analysis suggests
\nthat this abstracted complexity is the major cause of
\nmany privacy-related vulnerabilities, and that a fundamentally new, holistic, approach to privacy is needed
\ngoing forward. We thus highlight various existing technology gaps and propose several promising research directions for addressing and reducing this complexity.
\nKeywords: privacy-preserving technologies, mobile, Android, iOS
\nDOI 10.1515\/popets-2016-0018
\nReceived 2015-11-30; revised 2016-03-01; accepted 2016-03-02.
\nChad Spensky: University of California, Santa Barbara,
\ncspensky@cs.ucsb.edu
\nJeffrey Stewart: MIT Lincoln Laboratory,
\njeffrey.stewart@ll.mit.edu
\n1 Introduction
\nThe rapid proliferation of mobile devices has seen them
\nbecome integral parts of many users\u2019 lives. Indeed, these
\ndevices provide their users with a variety of increasingly
\nessential services (e.g., navigation, communication, and
\nInternet connectivity), as well as useful functionality
\n(e.g., entertainment and photography). To accommodate these services, modern mobile devices are equipped
\nwith various sensors, capable of collecting extremely rich
\ninformation about their users and their surroundings.
\nUsers and developers alike have embraced these datacollection technologies with open arms, in exchange for
\nthe rich set of high-tech features that they enable. In
\nfact, many of the apps offering these services are provided for \u201cfree,\u201d with an implicit exchange for access to
\nportions of this collected data, which is typically used
\nfor advertising [1].
\nUnfortunately, there is also evidence that users do
\nnot understand the extent of information being collected
\nabout them or the personal details that can be inferred
\nfrom this information. For example, a recent study on
\nbehavioral advertising showed that users did not understand how such advertising worked and found the
\ninformation that the advertisers had about them to
\nbe \u201cscary\u201d and \u201ccreepy\u201d [2]. Even when the users are
\naware of the data collection, one cannot expect them
\nto fully realize the non-intuitive implications of sharing
\ntheir data. Researchers have shown that the sensors on
\nthese devices can be used to covertly capture key presses
\n(taps) on the phone [3, 4] or a nearby keyboard [5], leak
\nthe users\u2019 location [6\u20139], record speech [10], or infer the
\nusers\u2019 daily activities [11].
\nPredictably, having millions of users carrying these
\ndata-collection technologies presents numerous privacy
\nArkady Yerukhimovich: MIT Lincoln Laboratory,
\narkady@ll.mit.edu
\nRichard Shay: MIT Lincoln Laboratory,
\nrichard.shay@ll.mit.edu
\nAri Trachtenberg: Boston University, trachten@bu.edu
\nRick Housley: Stevens Institute of Technology,
\nrhousley@stevens.edu
\nRobert K. Cunningham: MIT Lincoln Laboratory,
\nrkc@ll.mit.edu
\nUnauthenticated
\nDownload Date | 7\/11\/17 1:00 AM
\nSoK: Privacy on Mobile Devices 97
\nconcerns. The collected data may be accessible to a variety of parties, often without the explicit permission of
\nthe user. For example, companies that provide trusted
\nkernels [12\u201314], which are relatively unknown to the
\nuser market, have the technical means to access most
\nof the private user data that flows through their devices. Similarly, companies that advertise in mobile applications are able to learn a large amount of private
\ninformation about the user (e.g., gender, age, or home
\naddress [15]), and some location-based applications have
\nbeen shown to expose the users\u2019 fine-grained physical location not only to the application provider, but to the
\nworld [16, 17].
\nRecent high-profile data leaks have publicized compromising photographs [18], large numbers of credit
\ncards [19], and National Security Agency (NSA) documents [20]. Leaks of financial, authentication, or medical
\ndata can be used to access costly services (such as medical operations [21]) and could result in damages that are
\nextremely difficult to fix [22]. In this climate, it is not
\nsurprising that many users are concerned about their
\nprivacy [23] and have strong incentives to keep at least
\nsome of their data private. One survey, conducted in
\n2015, found that many Americans believed it to be \u201cvery
\nimportant\u201d to \u201cbe able to maintain privacy and confidentiality in [their] commonplace activities\u201d [24], while
\nanother found that 57% of users avoided or uninstalled
\na mobile application because of privacy concerns [25].
\nIn an attempt to address these concerns, numerous
\nprivacy-preserving technologies (PPTs) already exist at
\nevery level of the device stack (e.g., hardware, operating
\nsystem, application), and some companies even highlight these privacy features as part of their marketing
\ncampaigns [26]. However, the complexity of the modern
\nmobile-device environments, both hardware and software, and the piecemeal solutions offered by the individual components make security difficult to implement
\ncorrectly and privacy difficult to achieve. In fact, the
\nnumerous components are produced and provisioned by
\ndisjoint entities with differing interests and incentives.
\nIn effect, complexity can be the enemy of both security
\nand privacy, and the current on-device mobile ecosystem is especially complex.
\nIn this work, we shed light on this complex system
\nby surveying the numerous existing privacy-preserving
\ntechnologies, the components that each relies upon, the
\nparties involved, and the overall ecosystem they all cohabit. Our findings suggest that existing approaches
\nhave had marginal successes, but are likely going to continue to fall short of users\u2019 realistic privacy desires unless
\nthey are accompanied with fundamental changes to the
\nways that these devices are produced, provisioned, and
\nregulated.
\nWe scope our analysis to on-device technologies,
\nwhich we consider the users\u2019 first line of defense. Still,
\nwe recognize that a lot of private data may also leave
\nthe device and enter a \u201ccloud\u201d infrastructure, introducing additional privacy concerns that we leave for future work. We also focus on identifying gaps in today\u2019s
\nsystems and, rather than providing concrete solutions,
\nprovide high-level and speculative suggestions for future
\nresearch. Finally, whereas other studies have analyzed
\nprivacy on mobile devices (e.g., [3, 27\u201334]), we believe
\nour work is the first to examine the entire ecosystem
\n(i.e., hardware, software, human).
\nMobile differentiators The problems that we have
\noutlined underscore the unique challenges of the mobile
\ndevice ecosystem with respect to privacy. These challenges arise from the very nature of the devices, which
\nare 1) extremely sensor-rich, 2) continually proximate
\nto their users, 3) often accessed in public and through a
\nlimited interface, and 4) produced in a rapidly-changing
\ncommercial environment. Neither laptops, with their
\nlimited sensors, nor desktops, with their limited user
\nproximity, nor appliances, with their limited functionality and tightly controlled supply chain, provide the
\nsame level of deep-seated risks to the user\u2019s privacy.
\nContributions Our work includes the following primary contributions, with the goal of painting a holistic
\npicture of the overwhelming complexity in the mobile
\nprivacy space:
\n\u2013 We inventory critical privacy-related components
\non modern mobile devices, highlighting interactions
\nthat are likely unintended or unexpected.
\n\u2013 We identify the commercial entities currently responsible for deploying each technology.
\n\u2013 We itemize the various privacy-preserving technologies currently in use, calling attention to existing
\nand historical flaws and gaps.
\n\u2013 We enumerate the types of private data that are
\ncurrently accessible to the various parties.
\n\u2013 We describe several novel experiments that we performed to verify privacy-related claims.
\n\u2013 We highlight promising proposals that could help
\nalleviate some of the existing problems.
\nIndeed, we conjecture that achieving privacy in the current ecosystem is unlikely without fundamentally novel
\ntechnical and regulatory approaches.
\nUnauthenticated
\nDownload Date | 7\/11\/17 1:00 AM
\nSoK: Privacy on Mobile Devices 98
\n2 Mobile Privacy Ecosystem
\nWe begin our analysis by examining the components
\nthat comprise the mobile ecosystem (see Figure 1 for
\na brief summary). While mobile devices contain many
\nof the same components as traditional computing platforms, and face many of the same privacy-related problems, there are fundamental differences at each layer
\nthat can impact user privacy.
\nThe first differentiator between mobile and traditional computing platforms is the users\u2019 relationship
\nwith the devices, and the interfaces that they use to interact with them. More precisely, users typically carry
\ntheir mobile devices, in a powered-on state, with them at
\nall times, which is significantly different from the more
\nstationary use-cases of both laptops and desktops. Subsequently, many user\u2019s have developed a unique psychological connection with their mobile device, in extreme
\ncases developing an addiction [35]. Furthermore, while
\nhaving a small form-factor is convenient for mobility, it
\nalso restricts potential user interactions. For example,
\nwhile computers use separate input and output devices
\n(e.g., keyboard, mouse, screen), these interfaces are frequently integrated and overlapping in mobile devices
\n(e.g., touch screen), leading to various alternative interfaces (e.g., audio, vibration, motion). Moreover, this
\nsmaller, integrated, interface also restricts the amount
\nof information that can be conveyed to or received from
\nthe user, which can lead to sub-optimal privacy implementations (e.g., omission of security indicators [36]).
\nThe applications and operating systems that users
\ninteract with on mobile devices are also fundamentally
\ndifferent from traditional platforms. Historically, computers have provided relatively open environments, permitting developers essentially unfettered access to the
\nsystem and similarly allowing users to install any application and modify their system in any way that they
\ndesired. However, mobile-device providers have adopted
\na more closed ecosystem, typically restricting the device
\nto a single, pre-installed operating system, which is designed to only run applications written in a specific language (e.g., Java, Objective-C). These applications subsequently have very limited access to the system, using
\npre-defined application program interfaces (APIs), and
\nare cryptographically attributed to an author. Mobile
\ndevices have also attracted a significant amount of attention from advertisers, due to the rich data available
\non these devices that can be used to perform targeted
\nadvertising [37]. This advertising-focused profit model
\nhas led to a significantly different economic model from
\nUser Input\/Output Interfaces
\nApplications Application Code,
\nThird-party Libraries
\nOperating System
\nKernel, Drivers, Application APIs,
\nCryptographic Libraries,
\nSandboxing, App Verification
\nFirmware
\nFSBL, Bootloader, TEE Kernel,
\nBaseband RTOS, Cryptographic Keys,
\nSE & SIM OS
\nHardware
\nAP, BP, SIM, SE, Sensors, Touchscreen,
\nRadios, Power Controller,
\nCryptographic Chipset(s)
\nFig. 1. High-level abstraction of the components that constitute
\nmodern mobile devices.
\nthat of traditional computers, as the users\u2019 private data
\nhas become the primary currency for most developers.
\nFinally, mobile devices include a diverse medley of
\nhardware components to provide the rich experience
\nthat users have come to expect. Due to the relative complexity of each component, they are typically produced
\nby individual manufactures and then later combined
\ninto one unified device. Most of these hardware components have access to a lot of private information, which is
\nnot necessarily managed by the higher-level components
\non the device. Moreover, these hardware providers typically provide their own firmware and drivers to interact
\nwith their component, introducing even more complexity into the software environment.
\n2.1 Hardware Components
\nMobile devices contain a plethora of individual hardware components that interact using various protocols.
\nIn some cases, the components can interact and expose sensitive user data in ways that were not intended.
\nWhile the general hardware architecture of these systems has become extremely complex and varies wildly
\nbetween devices, there are still some overarching similarities in both the included technologies and their interconnections. Figure 2 diagrams the typical hardware
\nconfiguration found in modern smartphones.
\nApplication Processor (AP) The application processors (APs) on mobile devices are very similar to central processing units (CPUs) found in traditional computers, with a few caveats. First, because of the stringent power requirements of mobile devices, many of the
\nUnauthenticated
\nDownload Date | 7\/11\/17 1:00 AM
\nSoK: Privacy on Mobile Devices 99
\nApplication
\nProcessor
\n(AP)
\nTEE Coprocessors
\nMain
\nMemory
\nBaseband
\nProcessor
\n(BP)
\nSIM
\nFlash
\nMemory
\nRF
\nTranceiver
\nTouchscreen Sensors Camera
\nFlash
\nMemory
\nUSB
\nController
\nPower
\nController
\nSecure
\nElement
\nAudio Codec
\n(Microphone & Speaker)
\nWiFi\/BT NFC GPS
\nIndicates that the connection is architecture dependent, and not a common configuration.
\nWireless Modules
\nFig. 2. Typical hardware configuration for a modern mobile device.
\nAPs are designed with specialized low-power components and employ aggressive power-saving techniques
\n(e.g., halting cores). Second, unlike legacy CPUs, many
\nmobile devices utilize the system on a chip (SoC) model,
\nwherein various sub-components (e.g., connectivity, media, location) are all included in a single silicon chip.
\nComponents within the SoC frequently share resources
\n(e.g., memory), which can potentially leak private data.
\nFinally, many of the newer APs include a trusted execution environment (TEE), which provides hardwareenforced isolation for \u201ctrusted\u201d code, as well as the ability to arbitrate access to hardware components. These
\nTEEs can be leveraged to enhance both security and
\nprivacy, but also present another layer of complexity.
\nMobile Coprocessors In addition to the main AP,
\nmodern devices are equipped with additional coprocessors (e.g., Motorola\u2019s X8 [38] and Apple\u2019s M7 [39]) that
\nHelp the AP with various functions, each accompanied
\nwith their own firmware. More specifically, devices have
\nrecently been incorporating a natural language processor (NLP) for audio processing, and a contextual computing processor (CCP) for processing environmental
\ninformation (e.g., motion, light). These coprocessors are
\ntypically used to offload computation from the AP and
\nenable \u201calways on\u201d applications (i.e., the device can
\nstill be aware of it\u2019s surroundings while the AP and
\nscreen are in a power-saving state), which only wake
\nthe AP when a trigger event happens (e.g., saying \u201cOK,
\nGoogle,\u201d or handling the device). This always-on state
\ncould have serious privacy implications, as the users\u2019
\ndevices are likely collecting data about them even when
\nthey believe the device to be \u201coff.\u201d
\nBaseband Processor (BP) The baseband processors (BP) are typically multi-core processors that run
\na propriety real-time operating system (RTOS) as their
\nfirmware, which is provided by the BP vendor. Their
\nsole purpose is to handle cellular communications, and
\nthey are thus typically isolated from the rest of the hardware on the device, with the exception of the microphone, speaker, and subscriber identity module (SIM).
\nThis permits the BP to remain performant when handling voice calls, regardless of the load on the other components. While the ideal implementation would enforce
\nhardware isolation, it is typically cost effective to include the AP and BP on the same SoC, which could
\nallow the BP to access main memory [40], and subsequently a lot of private user data, in addition to the
\ncellular communications that it inherently controls.
\nUniversal Integrated Circuit Cards (UICCs) A
\ntypical mobile device will contain at least two UICCs,
\na SIM card for authentication to a mobile carrier, and
\na secure element (SE) for handling user credentials on
\nthe device itself. Both of these units contain yet another
\ncompletely self-contained processing unit in a securityhardened environment [41]. These components can be
\nleveraged to protect user data and credentials by providing an isolated environment for cryptographic operations, which is typically leveraged for authentication
\nand encryption. However, modern SIM cards can also
\nperform other actions on the device (e.g., send short
\nmessage service (SMS) messages, open a web browser,
\nand send messages over the network [42, 43]), which
\ncould be used to violate the users\u2019 privacy.
\nUnauthenticated
\nDownload Date | 7\/11\/17 1:00 AM
\nSoK: Privacy on Mobile Devices 100
\nCryptographic Hardware In addition to SEs, some
\nmanufacturers have recently begun including dedicated
\ncryptographic hardware for data encryption and authentication. For example, modern Apple devices have
\na dedicated module for encryption, using keys that are
\nfused into the application processor during manufacturing to make them inaccessible from software [44]. These
\ncryptographic modules can be utilized to protect the
\nuser\u2019s private data when the device is \u201clocked.\u201d
\nSensors Modern mobile devices are far more sensorrich than traditional computers, and are equipped with
\na wide variety of sensing capabilities (e.g., movement,
\nlocation, light). Additionally, numerous peripherals, or
\nwearables, also enable access to pedometers, heart rate
\nmonitors, and even sensors to detect blood oxygen levels. These sensors are the source of much of the private
\ndata collected by mobile devices, as even access to a
\nfew of these sensors can provide incredible insights into
\nthe user\u2019s private life. For example, with just location
\nand accelerometer data, Google is able to provide users
\nwith a complete log of their travels, including the mode
\nof transportation [45].
\n2.2 Software Components
\nWhile the general software architecture of mobile devices is similar to that of traditional computers, there
\nare a few key differences, which we briefly highlight.
\nTrusted Kernel Unlike historic computers, which only
\ncontained a single operating system, mobile devices frequently contain a separate, feature-rich, trusted kernel
\nwhich is used inside the TEE. This trusted kernel is the
\nmost trusted code on the device. Its job is to create an
\nisolated \u201cnon-secure,\u201d or \u201cnormal,\u201d world for the main
\noperating system (e.g., Android, iOS) to execute within.
\nThe trusted kernel and the main operating system interact using very limited interfaces (e.g., shared memory
\nregions), and the trusted kernel always maintains control of the non-secure world and has access to its entire
\nmemory space. Thus, the trusted kernel can undermine
\nany data protections or privacy-preserving technology
\ndeployed by the OS provider.
\nOperating Systems The major differentiator between
\nmobile OSs and their ancestors is primarily their closed
\nnature. They are typically more restrictive in both policing which apps are allowed to be installed, and subsequently restricting the app\u2019s access once it is installed
\nand executed. In order to restrict this access, mobile
\nOSs employ sophisticated permissions models and application sandboxing techniques.
\nMobile Applications In addition to the closed environment and advertising-focused economic model, the
\ntypes of applications available on mobile devices are
\nalso significantly different from traditional computers.
\nSpecifically, mobile applications are very likely to make
\nheavy use of their access to the various sensors. For example, numerous popular social applications leverage
\nthe users\u2019 precise location, and health-related applications collect intimate details about the users\u2019 personal
\nlives. However, many of these applications are developed quickly with functionality as their primary focus
\nand little thought given to user privacy, which can lead
\nto this personal data being mishandled (e.g., users\u2019 intimate encounters appearing on search engines [46]).
\nThird-Party Libraries Many of the applications
\navailable for mobile devices make use of third-party libraries, such as targeted advertising libraries [33], for
\nboth functionality and profit. However, users are often
\nunaware of the existence of these third-party libraries
\nin the apps. What\u2019s worse, because there is currently
\nno hard isolation between the components of an application, these libraries have the same access to data and
\nsensors as their parent application, which is frequently
\nleveraged to collect sensitive user data [15, 47].
\n2.3 Parties Involved
\nNumerous parties are typically involved in the deployment and provisioning of mobile devices, each responsible for different components. This significantly complicates privacy protection as the different parties may
\nhave varying incentives. Moreover, these parties often
\nretain control of their components after deployment
\nthrough over-the-air (OTA) updates. Understanding the
\nparties involved, and their access to, and control of, the
\ndevice is critical when analyzing the privacy assurances
\nthat are provided for mobile device data.
\nChip Vendors Unlike the AP, which typically runs
\nsoftware that was provided by the device provider, both
\nthe BP and UICCs typically come with pre-installed
\nsoftware from their respective manufacturers. Because
\nof these hardware components\u2019 privileged access in the
\ndevice, a vulnerability or backdoor could provide access
\nto private user data. In fact, Gemalto, a popular UICC
\nmanufacturer, recently made allegations that the United
\nStates\u2019 and Britain\u2019s intelligence agencies attempted to
\ncompromise their devices [48]. Furthermore, the area
\nUnauthenticated
\nDownload Date | 7\/11\/17 1:00 AM
\nSoK: Privacy on Mobile Devices 101
\nof malicious hardware has been gaining attention recently with recent publications showing just how practical these attacks are [49]. Detecting malicious hardware,
\nif it exists, has been shown to be extremely difficult [50].
\nOS Provider The operating system (OS), and thus
\nits provider, generally has access to a great deal of sensitive data. The OS is also responsible for ensuring adequate software-based segregation of applications and
\ndata sources. Most mobile OS vendors also employ remote administration capabilities, permitting them to
\nprovide updates post-deployment, as well as install and
\nremove applications [51, 52]. This could enable them
\nto change their protections or the amount of private
\ndata they collect, without informing users. More interestingly, many of the OS providers (e.g., Google, Apple)
\nalso have a strong incentive to collect private user data
\nto leverage for advertising or their own services [53].
\nTrusted Kernel Manufacturers Recently, the desire
\nto use the TEE has led to the advent of \u201ctrusted kernels,\u201d which come pre-installed on our mobile devices.
\nCompanies like Trustonic [54] and TrustKernel [13] provide this kernel to the device vendor, which then allow developers to install trusted applications within the
\nTEE. Trustonic claims to have their kernel installed on
\nmore than 400 million devices, and permits over-the-air
\n(OTA) updates of \u201cTrusted Services\u201d[14]. These parties
\nhave considerable power over mobile devices and an exploit in their firmware could be leveraged to completely
\ncompromise most security and privacy protections.
\nOEMs and ODMs The vendor that assembles the individual components into a mobile device for end users
\nis called the Original Equipment Manufacturer (OEM)
\nor Original Design Manufacturers (ODM) (e.g., Apple,
\nSamsung, HTC, LG). These vendors design the hardware system architecture, the connections between the
\nindividual components, and often provide the first-stage
\nboot loader (FSBL). In the case of the Android, OEMs
\ntypically modify the OS to incorporate specific hardware functionality, pre-install applications, add or remove features, and add services to ensure continued
\ncontrol over the device once it is deployed. Recently,
\nOEM vendors have also started including their own interfaces and functionalities (e.g., Samsung\u2019s Knox[55])
\nin the TEEs of their devices. Even when the OEMs have
\nthe best of intentions, they are still capable of introducing severe vulnerabilities [56] as they are frequently
\nincreasing the complexity and attack surface of the OS.
\nMobile Internet Service Providers (MISPs) Most
\nmodern devices rely heavily on Internet access provided
\nby mobile Internet service providers (MISPs). In fact,
\nmany of the mobile devices on the market today are
\nsold directly by MISPs. These MISPs inherently can observe all unencrypted traffic, and can trivially ascertain
\nthe rough physical location of devices using triangulation with their broadcast towers. The 3GPP, a partnership of communications interests, outlines the specifications for lawful interception of communications [57].
\nMany MISPs have far more access on devices than their
\nrole of providing Internet access would suggest. In many
\ncases, they can remotely update the functionality of the
\nSIM [58], which has access to numerous functions on the
\ndevice enabling it to obtain global positioning system
\n(GPS) coordinates, open a browser, and communicate
\nwith the BP and the AP.
\nApplication Developers Mobile application developers inherently have the least-privileged access to the
\nprivate data. However, most of the device\u2019s functionality
\nto users is provided through these applications. Thus,
\nexposing hardware sensors and other data sources to
\nthese applications is typically necessary. While most of
\nthese queries for data (e.g., GPS coordinates) will alert
\nthe user, it has been shown that most users will blindly
\naccept these requests without much concern for how the
\ndata will be used [29].
\nThird-party Library Providers Instead of developing entire applications, some developers focus on creating libraries that can be included in other applications
\nto provide specific functionality (e.g., cryptography, advertising, or graphics). Many developers use these libraries, exposing their data to the library provider.
\nIn particular, in exchange for monetary compensation,
\nnumerous applications include advertisement libraries.
\nResearchers found that as many as 52.1% of applications utilize ad libraries [33]. Therefore, these adlibrary providers can access a vast amount of user data
\nspanning numerous applications and operating systems.
\nZang et al. found that 73% of Android apps shared personal information (e.g., name and email) and that 47%
\nof iOS apps shared location data with third parties [59].
\nMobile Device Management Many employers either provide mobile devices to their employees, or encourage them to bring your own device (BYOD), allowing employees to use their personal devices for business purposes. In both cases, the employer typically requires a mobile device management (MDM) solution to
\nbe installed, which provides the employer with a great
\ndeal of control over the device (e.g., install\/blacklist applications, modify security settings, and location trackUnauthenticated
\nDownload Date | 7\/11\/17 1:00 AM
\nSoK: Privacy on Mobile Devices 102
\ning). Employees storing personal data on MDM-enabled
\nphones, and carrying them during off-business hours,
\npresents some interesting privacy concerns that, to the
\nbest of our knowledge, have been left mostly unexplored.
\n2.4 Summary
\nThe mobile-device ecosystem is a unique environment
\nwith numerous perils for user privacy. Unlike most desktop and laptop computers, mobile devices are filled with
\nsensors that can collect a vast amount of sensitive data
\nsince the devices are typically always on and always with
\ntheir user. Complicating things further, the hardware
\ncomponents of the mobile-device ecosystem, and their
\nassociated drivers, are provided by multiple vendors and
\npotentially give these providers access to sensitive user
\ndata. Furthermore, software developers are allowed to
\ndistribute their own code to these devices in the form
\nof apps with many of these monetizing the available
\nuser data through third-party advertisement libraries.
\nThe result is an ecosystem with multiple agents that
\nhave access to private user data and a clear incentive to
\ngather, exploit, and share this private data.
\n3 Protecting Private Data
\nIn this section, we review the numerous privacypreserving technologies and techniques employed on
\nmodern mobile devices, across all levels of the stack.
\nThese protections are deployed in an effort to add security and privacy to the various components of the mobile
\necosystem discussed in Section 2. In our presentation,
\nwe highlight the aspects of the technologies that make
\nthem particularly interesting on mobile devices. Additionally, we restrict our analysis to Google\u2019s Android
\nand Apple\u2019s iOS platforms, which account for 97.8% of
\nthe smartphone market [60].
\n3.1 Hardware-based Mechanisms
\nBoth Android and iOS leverage hardware-based features
\nfor protecting the privacy and security of sensitive data.
\n3.1.1 Trusted Execution Environment (TEE)
\nTEEs provide a hardware-enforced isolated execution
\nenvironment for security-critical code, which can provide a safe haven for storing and processing sensitive
\ndata. The general concept behind TEEs is that this
\n\u201ctrusted,\u201d or \u201csecure,\u201d world, can be verified using techniques like secure or authenticated boot [61] and can be
\nleveraged to maintain a root of trust on the device, even
\nwhen the \u201cnormal,\u201d or \u201cnon-secure,\u201d world is compromised. The most popular of these, due to their market
\ndominance, is ARM\u2019s TrustZone [62].
\nThis functionality is available on all modern ARM
\ncores and has only recently started to be leveraged to
\nprotect user data. For example, both Android [63] and
\niOS [44] are using this technology to protect fingerprint
\ntemplates and Samsung has deployed Knox [55], which
\nis used to provide segregation between the user\u2019s personal and work-related data on the device. However,
\nvendors have only begun to scratch the surface, as this
\ntechnology could also be leveraged to arbitrate access
\nto the hardware-based sensors, potentially employing
\nother privacy-preserving technologies to help thwart unintended disclosures. Similarly, it is possible to leverage
\nthe TEE to provide a secure trusted path (e.g., by dynamically reconfiguring the hardware permissions) for
\nusers to both input and digest sensitive information
\n(e.g., passwords, private messages, pictures).
\n3.1.2 Data at Rest Encryption
\nSimilarly, both Android and iOS leverage hardwarebacked technologies to implement full-disk encryption,
\nwhich protects all of the data on the device when it is
\n\u201clocked\u201d or powered off. Specifically, both Android and
\niOS use the TEE to prevent the underlying encryption
\nkeys from off-device brute force attacks [44, 64]. Apple
\ntakes this protection a step farther by introducing a dedicated cryptographic hardware unit between the volatile
\nsystem memory and non-volatile flash storage. Because
\nthe cryptographic hardware is separated from the AP,
\nthe TEE can provide it with encryption keys without exposing them to the OS. This protects the user\u2019s privacy
\nby ensuring that even if an attacker can compromise
\nthe iOS kernel, they will be unable to steal the encryption keys needed to recover the data [44]. Android, on
\nthe other hand, implements full-disk encryption via the
\nLinux kernel, based on dm-crypt [65], which stores the
\nencryption key in kernel memory while in use.
\nThe effectiveness of these techniques was recently
\ndemonstrated in a high-profile case, wherein the Federal Bureau of Investigation (FBI) was unable to recover
\ndata from an iOS device [66].
\nUnauthenticated
\nDownload Date | 7\/11\/17 1:00 AM
\nSoK: Privacy on Mobile Devices 103
\n3.2 Software and User-based Mechanisms
\nWe now describe the various tools used to control which
\napplications may run on a mobile device, restrict the private data that these applications may access and collect,
\nand protect the sensitive data once it is collected.
\n3.2.1 Application Vetting
\nOne of the main selling points of modern mobile devices is their ability to run applications. In fact, the
\nAndroid and iOS app markets both tout over 1.5 million apps, offered by a variety of third-party developers [67]. However, these developers can be untrustworthy or downright malicious [31, 68\u201372]. Therefore, both
\nGoogle and Apple employ strict application vetting processes for their app stores, which check for violations
\nof the developer policies and privacy-invasive behavior.
\nWhile their approaches are quite similar, previous work
\nsuggests that vetted Android apps end up accessing less
\nsensitive data than iOS apps [27].
\nAndroid Google offers an official app store, which
\nit calls Google Play [73]. However, Google also allows
\nusers to purchase apps from a number of third-party
\napp stores (e.g., Amazon [74]). In fact, the Google Play
\nstore is not available at all in China [75], forcing all Chinese users to obtain their apps from third-party stores.
\nBefore being included in Google Play, an application must pass Google\u2019s vetting process, which ensures
\nthat the app does not violate the Google Play developer policies, many of which restrict the use of private
\nuser data [76]. Recently, Google\u2019s app-vetting process
\nhas started to include manual, human, checks [77] (similar to Apple\u2019s review process), in addition to their automated analysis.
\nHowever, this app-vetting process still suffers from a
\nfew deficiencies. First, the Android vetting process was
\nhistorically only performed on applications that were
\nsubmitted to Google Play. Thus, if the application was
\nsubmitted to another app store or downloaded from an
\nunknown source, the vetting was not performed; however, installing these applications still required explicit
\nuser consent. Nevertheless, Google recently introduced
\nVerify Apps Protection, which automatically uploads
\nand scans applications before installing from unknown
\nsources [78]. Second, Android does not require the application code to be cryptographically signed before execution (i.e., developers can dynamically load program code
\nafter the vetting process). Therefore, a privacy-invasive
\napplication could pass the Google Play app vetting process, and then, when executed, download malicious code
\nand run it. In fact, this technique has been abused by
\nprivacy-invasive malware in the wild [79].
\niOS Unlike Android, iOS only allows apps to be installed from the Apple App Store, which requires the
\napp to have passed their vetting process. In addition to
\nscanning for known malware and functionality checks,
\none of the major components in the Apple vetting process is to scan for applications that are using private
\nAPIs. While internally the low-level iOS Objective-C
\nand C libraries contain many private methods, which
\nare not documented in the official iOS API, iOS applications submitted to the App Store are required to only
\nuse the publicly documented APIs. Because these methods are called from within the public APIs, they cannot be completely removed from production. However,
\nmany of these methods are dangerous and have the ability to retrieve private information. For example, in our
\nexperimentation (detailed in Section 4.3.2), we found
\nprivate API classes (i.e., ACDServer) that when initialized causes the main GUI on iOS 9.0 to crash. Additionally, previous work has found that many of these private
\nAPIs can be used to retrieve private data [72, 80\u201383].
\n3.2.2 Application Sandboxing
\nBoth Android and iOS provide isolation mechanisms,
\ncalled application sandboxes, which prevent applications from interfering with one another and from accessing resources that they do not possess permissions for.
\nBoth OSs reuse kernel-level security features that were
\npreviously designed for commodity operating systems
\nto provide separation and a mechanism for enforcing
\nmandatory access control (MAC).
\nAndroid Android\u2019s sandboxing capabilities center
\naround Linux\u2019s user separation [84]. Android leverages
\nthis separation by assigning each installed application a
\nunique user identifier (UID). The Linux kernel then enforces resource isolation to ensure that one application
\ncannot interfere with another application (e.g., reading\/writing their files, sending signals, debugging, etc.).
\nFurthermore, Linux also provides Android with a mechanism to restrict an application\u2019s resource consumption
\n(e.g., memory and CPU) and its access to the various
\ndevice sensors. More recently, Android has also been
\nemploying SELinux\u2019s MAC framework to apply more
\nfine-grained access control policies to applications [85].
\nUnauthenticated
\nDownload Date | 7\/11\/17 1:00 AM
\nSoK: Privacy on Mobile Devices 104
\niOS Unlike Android, far less is known about the mechanisms behind iOS\u2019s sandboxing implementation. The
\nmajority of what is known about Apple\u2019s sandbox implementation was learned through reverse engineering
\nthe implementation [86\u201388]. However, the underlying
\ntechnology, TrustedBSD, is open source and detailed
\nin Robert Watson\u2019s PhD Dissertation [89]. iOS\u2019s TrustedBSD MAC framework introduces additional checks
\nin the kernel against the MAC profile\u2019s policy for various actions (e.g., reads and writes to a file, listing the
\nfiles in a directory). These policies are provided by two
\nkernel extensions: Apple Mobile File Integrity (AMFI),
\nwhich implements the code signing and permission system; and Sandbox.kext, which implements the sandboxing components. Sandbox.kext implements sandboxing
\nthrough the use of many built-in Scheme-like policies,
\nwhich describe precisely what a process can and cannot
\ndo. There were 95 unique sandbox profiles found in iOS
\n8.0, and all third-party apps were assigned the \u201ccontainer\u201d profile, which generally restricts the application
\nto only access files within its own directory [88].
\n3.2.3 Permissions Models
\nWhile sandboxing applications prevents them from interfering with the device or stealing the users\u2019 data,
\nthere are plenty of legitimate reasons that apps may
\nneed to access sensitive resources. Both Android and
\niOS have run-time permissions models that require users
\nto explicitly approve an application\u2019s request to access
\nprivate data or potentially dangerous functionality.
\nAndroid The Android architecture divides permissions
\ninto two categories: normal and dangerous permissions.
\nDangerous permissions are needed for actions that appear to pose a risk to a user\u2019s privacy or the device\u2019s operations (e.g., location, phone operations, microphone),
\nwhereas normal permissions correspond to less risky actions (e.g., access the Internet, vibrate, set timezone),
\nand may be revoked at any time. For dangerous permissions, user approval is required for all permissioncontrolled actions that it may undertake before the app
\nwill even be installed. Starting with Android 6.0, the
\nuser must also approve dangerous permissions the first
\ntime they are actually utilized; however, in the interest
\nof usability, approval of one permission provides access
\nto an entire group of permissions. For example, runtime approval of coarse-grain localization also covers
\nlater actions involving fine-grain localization. An example of one such permission dialog in Android is given
\n(a) Android (b) iOS
\nFig. 3. User permission dialogs for Android [93] and iOS [94].
\nin Figure 3a. This more recent permissions model resembles the permissions dialogs in iOS and aims to reduce over-permissioning [90], which arises when applications request a large number of permissions up front,
\nin case they may be useful later. Previous research has
\nshown that users often did not understand the installtime permissions dialogs and were often surprised by
\nthe data that these over-permissioned apps could access [29, 91, 92]. On the other hand, normal permissions
\ndon\u2019t pose such a risk, and are automatically granted at
\ninstall time (i.e., the user is not prompted).
\niOS The permission system in iOS uses two separate mechanisms to delegate access to the system, entitlements and permissions. Entitlements are rights set
\nin an application\u2019s configuration and give the application a specific capability that it would otherwise not
\nhave (e.g., background processes, iCloud access) [95].
\nThese entitlements are set in the app bundle that gets
\nsigned by Apple and therefore cannot be modified after the application is submitted to the App Store. Permissions, alternatively, are only approved at run-time,
\nwhen the application actually attempts to access the
\nrestricted resource. When an application first attempts
\nto access any restricted functionality or data (e.g., location, microphone, user contacts), iOS will prompt the
\nuser for approval (see Figure 3b), and the access will
\nbe granted only if the user agrees. The user\u2019s response
\nto this prompt is saved, and any future attempt to access the same resource is subsequently approved. Unlike
\nentitlements, which are approved by Apple when the
\napplication is submitted to the App Store, these permissions can be approved or revoked by the user at any
\ntime though iOS\u2019s menu system.
\nUnauthenticated
\nDownload Date | 7\/11\/17 1:00 AM
\nSoK: Privacy on Mobile Devices 105
\n3.2.4 Data in Transit Encryption
\nBoth Android and iOS provide APIs that allow applications to make secure network connections using
\nSSL\/TLS [96, 97]. These APIs ensure that applications
\ndo not leak private data to the MISP, a WiFi provider,
\nor any malicious party that may be listening to external communications. In order to prevent the use of weak
\nand broken cryptography, which may be vulnerable to
\ncryptanalysis, Android disabled the use of weak cipher
\nsuites starting with Android 5.0 [98]. Apple has gone a
\nstep further, by mandating that applications on iOS 9.0
\nand later must use transport layer security (TLS) 1.2
\nwith forward secrecy or an exception will be thrown,
\nand the connection will not be made [99]. Additionally,
\nin an attempt to reduce the number of unencrypted connections, Apple has begun forcing developers to specifically whitelist any domains that an application wants
\nto make any unencrypted web requests to.
\n3.2.5 Privacy Policies
\nIn addition to the technical tools for controlling access to private data, mobile devices also make use of
\nregulatory mechanisms in an effort to protect users\u2019
\nprivacy. Specifically, application developers often have
\nprivacy policies that govern the collection and use of
\nprivate data by their apps. These policies are required
\nby Apple and Google when accessing specific data on
\na device [100, 101], and are intended to inform users
\nabout how their information will be collected, stored,
\nand used. Privacy policies can also sometimes be used
\nfor regulatory and legal action to enforce privacy protections; however, this is beyond the scope of this paper.
\n3.3 Summary
\nThis section describes many of the tools currently deployed for protecting user privacy on mobile devices.
\nAn interesting observation is that there has been a significant focus on user-in-the-loop permissions to regulate access to this data (i.e., requiring explicit input
\nfrom users). Moreover, regulating this access to private
\ndata is made even more important by the sheer number, and general untrustworthiness, of application developers. It is also worth noting that, for the most part,
\nthese privacy-preserving technologies exist in isolation,
\nassuming the soundness of each other to ensure user privacy. For example, 1) the OS assumes that the vetting
\nprocess was successful, that the user will act appropriately when prompted for access to sensitive data (e.g.,
\nFigure 3), and that the application will not leak this data
\nin unintended ways; 2) the app assumes that the OS\u2019s
\nsandboxing will protect it\u2019s data, and 3) both the OS
\nand app assume that the TEE and full-disk encryption
\nwill protect their stored data. While there have proposals that take a more system-wide approach for protecting user data [102, 103], we are unaware of any that are
\nable to also account for the hardware components.
\n4 Remaining Privacy Leaks
\nDespite the best efforts of both the users and the technology providers, mobile devices continue to fail at
\nprotecting user data. Many of the issues stem from
\nthe complexity of the mobile ecosystem and have resulted in vulnerable implementations and fundamental
\ndesign flaws. This section describes the remaining privacy leaks, within the various layers of the device, and
\nthe types of data leakages that result. These leakages
\nare broadly summarized in Table 1, which demonstrates
\nthe significant exposure of vast amounts of private data,
\nat all levels of abstraction, to a variety of parties.
\n4.1 Hardware Components: Baseband,
\nSIM, and TEE
\nMany of the hardware components in mobile devices
\npresent unique challenges to the protection of user\u2019s private data. For instance, the Baseband Processor, SIM
\ndevices, and TEE are all generally considered black
\nboxes; however, they can all access a substantial amount
\nof user data, without much limitation.
\nThe BP\u2019s role in the device\u2019s infrastructure allows
\nit to observe all of the communications between the device and the MISP. This means that not only can it leak
\nthis private communication elsewhere, but that the BP
\ncan also be accessed and exploited through the same
\nchannel (e.g., via a nearby malicious cellular base station [126]). Xenakis et al. [30] showed that, once compromised, the BP can be used to access the device\u2019s GPS
\ncoordinates, calling number, international mobile subscriber identity (IMSI), and even the keys that are used
\nto encrypt communication with the MISP via the SIM.
\nMiller et al. [115] demonstrated a vulnerability in a BP\u2019s
\nfirmware that converted affected iPhones into a remote
\nlistening device, and a similar vulnerability was recently
\nUnauthenticated
\nDownload Date | 7\/11\/17 1:00 AM
\nSoK: Privacy on Mobile Devices 106
\nProvider of Component
\nHardware \/ Firmware Software Network Malicious
\nAP
\nBP
\nSIM
\nTEE
\nOS
\nApps
\nLibraries
\nMISP
\nMitM
\nPhysical
\nApp
\nRemote
\nType of Data Available
\nPersonal
\nAddress Book [62] ? [59],[33]A [42, 43] [56]A [104]A[105]i
\n[106][107]A [106][107]A
\nE-mail [62] ? [59] [56]A [104]A[105]i
\n[106][107]A [106][107]A
\nPrivate Files [62] ? [56]A [104]A[105]i
\n[106][107]A [106][107]A
\nUnique Identifiers [30] [42, 43] [62] ? [59],[33]A [42, 43, 108] [28, 108, 109][56]A [104]A[105]i
\n[106][107]A[81, 83, 110, 111]i
\n[106][107]A
\nCall\/SMS (Logs) [30] [33]A [57] [56]A [104]A[105]i
\n[106][107]A [106][107]A
\nCall\/SMS (Live) [30] [57] [112]A N\/A [106][107]A[111]i
\n[106][107]A
\nEnvironment Physical Location [113] [42, 43] [62] ? [59],[33]A [42, 43, 57] [28, 109][56]A [104]A[105]i
\n[6\u20139, 106] [16, 114]
\nMicrophone [113][115]i
\n[62] ? [56]A [104]A[105]i
\n[10, 106][107]A [10, 106][107]A
\nCamera [113] [62] ? [33]A [56]A [104]A[105]i
\n[106][107]A[80, 81]i
\n[106][107]A
\nPhysical Sensors [62] ? [56]A N\/A [106][107]A [106][107]A
\nCredentials TEE [104]A [116\u2013118]
\nSIM & SE [30] [30, 119] [120] [30, 119] [119]
\nApps [62] [59] [121][56, 75, 122]A [104]A[105]i
\n[3, 4, 123][111]i
\n[124, 125]
\n– Access to the data is implied by the role of component ? – Access to the data is permitted after explicit user interaction
\nA – Android Only i – iOS Only
\nTable 1. Enumeration of which parties have been shown to have access to specific types of private data on modern mobile devices.
\ndemonstrated against the Samsung\u2019s Galaxy S6 running
\nAndroid [112]. In fact, the baseband on the iPhone has
\nbeen exploited repeatedly to \u201cunlock\u201d iPhones, which
\nwere locked to a specific MISP [127]. Moreover, depending on the implementation, the BP could also be used
\nto obtain data from user applications through the AP,
\nor directly, using direct memory access (DMA) [113].
\nThe great care given to the security of SIM devices
\nmakes them very difficult to analyze (e.g., most production SIMs do not permit the installation of third-party
\napplications). Nevertheless, researchers have found vulnerabilities in SIM\u2019s protocols [128] and software [119],
\nin addition to physical attacks [120], which permit access to the critical on-board data. These vulnerabilities
\ncould permit attackers to clone the device or decrypt
\nnetwork traffic, in addition to the other SIM capabilities
\n(e.g., capturing GPS coordinates, sending messages, and
\ndisplaying content on the users\u2019 screen [42, 43, 119]). In
\nfact, a recent proof-of-concept malware was created that
\ncould obtain sensitive data from the SIM by Question Assignmenting it
\nfrom the AP via the BP [30].
\nFinally, numerous vulnerabilities have been discovered in the implementation of the \u201csecure world\u201d code
\nin TEEs (e.g., Huawei\u2019s HiSilicon [117], Qualcomm\u2019s
\nMSM8974 [118] and Snapdragon [116, 129]). With access to code execution in this trusted world, an attacker
\ncan gain access to all of the data available on the device,
\nincluding cryptographic keys, application data, biometric data, and sensor data. Thus, some research has focused on shrinking the trusted elements [130], so that
\nthey can be verified formally or by hand. Nevertheless,
\nthe popularity and trust placed in the TEE continues
\nto grow together with the concern for privacy breaches.
\n4.1.1 Firmware\/Drivers
\nMany of these hardware components contain their own
\nfirmware and are accompanied with drivers to enable
\ncommunication with them. Most OS-providers blindly
\ninclude these drivers, trusting them with privileged access to the system. However, drivers have long been exploited [131], and could pose a serious a risk to the
\nuser\u2019s privacy if they expose a vulnerability. In previously unpublished work, we analyzed the attack surface
\nof near-field communication (NFC) interfaces on mobile
\ndevices by developing and exercising a physical-layer
\nNFC fuzzing framework [132]. In this work, we examined the Nexus S and the Nexus 4, two flagship Android
\nphones (running version 4.1.2 and 4.2.2 respectively).
\nWe conducted over 132,000 fuzz tests on the Nexus S,
\nobserving 856 crashes, and over 150,000 fuzz cases on
\nUnauthenticated
\nDownload Date | 7\/11\/17 1:00 AM
\nSoK: Privacy on Mobile Devices 107
\nthe Nexus 4, observing only 7 crashes. Many of these
\ncrashes appeared in the drivers themselves, indicating
\nthat the significant difference in the number of observed
\ncrashes is likely due to the NFC chipset and their accompanying drivers, as the software versions were essentially identical. This experiment further emphasizes the
\ncompounded complexity that occurs in mobile devices,
\nwith their various third-party hardware dependencies.
\n4.2 Sensors
\nUnlike general purpose computers, almost all mobile devices contain a GPS sensor for detecting physical location. In some cases, this location information could be
\nused to infer a significant amount about the user\u2019s activities (e.g., illegal, embarrassing, or \u201csecret\u201d locations)
\nor personal characteristics (e.g., at a club that caters to
\nparticular social interests). While numerous protections
\nexist to protect this valuable data (e.g., requiring explicit user-granted permission), numerous side-channels
\nhave been shown, which still leak accurate location data.
\nFor example, proximity-based dating apps share the
\nuser\u2019s location with the provider to find potential nearby
\ndates, and these providers have been shown to leak the
\nuser\u2019s location (with varying granularities) to anyone
\nwith an app-related connection to the user [16, 114].
\nFurthermore, local WiFi network signal strength [6] or
\navailability [133], accelerometers [7], and even ambient
\nsound and light [9] have also been shown to leak location
\ninformation.
\nUsers also frequently enter private credentials into
\ntheir devices through user-interfaces such as the touchscreen, camera, or microphone. These user-interfaces,
\nrestricted by the size of the device and commonly accessed in public venues, can leak access to data over
\nsignificantly more channels than their less-mobile desktop and laptop counterparts. Beyond a bystanders\u2019 ability to view the screen or overhear conversations, it has
\nbeen shown that the keyboards on touch screens are inherently susceptible to being observed [124], even when
\ndirect line-of-sight is not available [125]. Similarly, data
\nfrom the device\u2019s accelerometer and\/or microphone has
\nbeen leveraged to infer user key presses [4] and tap locations [3, 123] on the touch screen. These methods
\ncould be used to covertly intercept users\u2019 passwords, financial information, and private communications from
\na background app with access to the sensors. Further,
\nMichalevsky et al. [10] recently demonstrated that the
\ngyroscope, which is accessible to applications and websites in both Android and iOS, could be utilized to identify speaker information and even parse speech.
\n4.3 Operating System
\nDue to the OS\u2019s visibility, and its position as the first
\nline of defense against malicious applications, it is unsurprising that almost every aspect of the OS has subsequently been targeted and exploited to obtain private
\ndata. We highlight the most notable examples below.
\n4.3.1 Bloatware and Updates
\nOne of the major distinctions between Apple and Android devices relates to their control over the device: Apple has significantly more control over many of the components with which iOS interacts (including hardware),
\nwhereas Android is more commonly modified and distributed by various third-party vendors before it reaches
\nthe user. For example, Apple restricts the applications
\nthat are bundled with the device, whereas Android devices typically come with a variety of such applications
\npre-installed, often with unwanted and unknown (to
\nthe user) privacy-invasive features [34, 134, 135]. Unlike desktops and laptops, which may also come with
\npre-installed bloatware, users on mobile devices often
\nhave no means to remove it, resulting in a much longer
\nsustained privacy invasion. These Android modifications
\nhave led to vulnerabilities [136], and some vendors have
\nabused this privilege by adding \u201cspecial features\u201d (e.g.,
\nremote access) to the devices [137, 138]. Most notably,
\nSamsung was recently accused of modifying the version of Android running on their devices to implement
\nremote-control functionality from the BP [139].
\nSimilarly, because of the distributed Android
\necosystem, system updates can take a much longer time
\nto apply to all devices than for iOS, where Apple can
\npush updates unilaterally. The result of these delayed
\nupdates was shown in a recent study of the Android
\necosystem, which found that 87.7% of devices were vulnerable to at least one critical vulnerability [140], partially due to the slow updates. This is in stark contrast
\nto general purpose computing, where patches for critical
\nvulnerabilities are often deployed as quickly as possible.
\nUnauthenticated
\nDownload Date | 7\/11\/17 1:00 AM
\nSoK: Privacy on Mobile Devices 108
\n4.3.2 Permissions and Sandboxing
\nAs described previously, both Android and iOS have
\nsandboxes and permissions systems to restrict thirdparty application developers from accessing the private
\nsensor data available on the mobile platforms.
\nAndroid The Android permissions model is designed
\nto allow users of Android devices to control what data
\nmay be collected by the applications installed on their
\ndevices [141]. In principal, this should allow the user to
\nbe aware of all sensitive data accessed by any application installed on their device. However, as our experiments detailed below indicate, this is not always the
\ncase. Often times, unintended side-channel attacks permit the recovery of more information than was originally intended (e.g., taps [3, 4], keypresses [5], position [6, 7, 9, 10], current activity [11]). For instance,
\nMichalevsky et al. recently demonstrated the ability to
\nrecover a phone\u2019s location from the seemingly innocent
\nability of an application to measure the phone\u2019s aggregate power use [8].
\niOS As mentioned in Section 3.2.1, Apple has specifically forbidden the use of private APIs by applications, because they may leak private user data. However, there has been a large body of work on bypassing
\nthe application vetting process in order to allow private API usage. For example, Han et al. [80] were able
\nto get several privacy-invasive apps (e.g., secret filming
\nand screen capturing) through Apple\u2019s vetting by utilizing private API calls in dynamically loaded and obfuscated libraries. Other applications have successfully
\nevaded the vetting process by implementing hidden remote vulnerabilities, which, post-vetting, permitted remote agents to divert execution into a previously \u201cdead\u201d
\ncode branch that would dynamically load the needed libraries to make private API calls [81].
\nTo prevent these attacks, Bucicoiu et al. used static
\nbinary rewriting to modify an iOS application\u2019s code to
\ninclude a reference monitor to restrict the use of private
\nAPIs [82]. Similarly, Deng et al. developed a system, using static analysis, dynamic analysis, and forced execution, to detect private API use and found 146 approved
\nthat were using private APIs [83]. Furthermore, another system, that used static analysis and simple string
\nde-obfuscation techniques, was able to identify 256 approved apps using these privacy-invasive APIs [142].
\nA design flaw in Apple\u2019s enterprise app model has
\nbeen shown to permit the publication of completely unvetted applications to the public [111]. Because these
\napplications are signed with an enterprise certificate,
\nthey are not vetted by Apple and can utilize private
\nAPIs without restriction. Recent research analyzing
\nthese publicly distributed enterprise apps found that
\n80% of the analyzed apps do, in fact, utilize private
\nAPIs, primarily to obtain private user information [111].
\nUnsurprisingly, iOS malware has also utilized this technique to infect un-jailbroken devices [72, 143, 144].
\nExperiment In order to analyze the existing permissions models for sensitive data leakage, we conducted
\nan experiment to determine the amount of private data
\nthat is currently available to applications with no explicit permissions [145].
\nOn Android (version 5.1.1), we used Java\u2019s reflection to traverse the class hierarchy in the runtime environment, allowing each of the fields and methods for
\nall of the available classes to be accessed and analyzed
\nfor private data. While complications arise from the
\nneed to supply the correct arguments for object constructors and other methods, these can be mitigated
\nby recursively creating the needed arguments and utilizing the results of previous method calls. This technique identified numerous unique identifiers that could
\nbe used to fingerprint the device (e.g., directory structures and account authenticators), discern the user\u2019s interests (e.g., installed applications and associated metadata), obtain the user\u2019s personal information (e.g., device wallpaper), and learn the fine-grained per application network throughput, which can be exploited for a
\nnumber of side-channel attacks (e.g., decrypting voice
\nover IP (VoIP) [146\u2013148], website fingerprinting [149]).
\nThis experiment was similarly conducted on iOS
\n(versions 8.1.3 and 9.0); however, the effectiveness
\nwas hindered by a number of complications, such as
\nObjective-C\u2019s lack of memory safety, type safety, and
\ncomplete reflection support. However, our unprivileged
\ntest application was still able to obtain a few noteworthy results: modifying the device\u2019s volume without
\nuser interaction; causing the main GUI, SpringBoard,
\nto crash; causing other processes, such as geod (the location provider service daemon) to crash; and causing
\nthe OS kernel to crash.
\nOver-Permissioning One of the simplest methods of
\ncollecting private data from a user is to simply request
\naccess to it upon installation. Once the user agrees to
\nthe permissions, future updates of the app can then exercise those permissions. Various studies have approximated that a significant amount of Android applications
\n(one-third of 940 [90], 44% of 10,000 [150]), in fact, request permissions that they do not use. Moreover, this
\ntrend of over-permissioning appears to be increasing in
\nUnauthenticated
\nDownload Date | 7\/11\/17 1:00 AM
\nSoK: Privacy on Mobile Devices 109
\napplications [151] and the use of these permissions has
\nbeen similarly growing in advertisement libraries [152].
\nData collected by an over-permissioned application
\ncan typically be exfiltrated to the Internet, since such
\naccess is provided by default on both Android and iOS.
\nTo combat this risk, several systems attempt to identify user data that is sent off device by an application.
\nPiOS uses static analysis on iOS applications to detect
\ncode flows which first access user data and then utilize
\nthat data in network API calls [153]. TaintDroid took
\nthis analysis one step further by modifying Android to
\nconduct system-wide dynamic taint tracking to detect
\nnetwork transmission of user data [103].
\n4.3.3 Full Disk Encryption (FDE)
\nOn Android, the OS is also responsible for managing
\nthe full disk encryption, which is based on the Linux
\nkernel\u2019s dm-crypt. Previous work has shown that once
\nan application can read the Linux kernel\u2019s memory, it is
\npossible to steal these encryption keys [154], revealing
\nthe sensitive data. Similarly, Android is also vulnerable
\nto memory dumps, as shown by M\u00fcller et al. [104], who
\nobtained the encryption keys via a cold boot attack.
\n4.4 Application
\nIn addition to the various OS-level protections, application developers also have a strong incentive (i.e., reputation) to protect the private user data that they are
\nlegitimately collecting, and thus employ various techniques to implement these protections.
\n4.4.1 Data in Transit Encryption
\nUnless network encryption is properly used, any private data sent over the network could be trivially intercepted (e.g., by a Man-in-the-Middle (MitM) or wireless
\nprovider). As such, there have been a large number of
\nstudies investigating applications\u2019 use of encryption in
\ntransit on both iOS and Android [75, 121, 122, 155\u2013163],
\nrevealing a wide range of flaws that leaked user data.
\nMore precisely, mallodroid [164], an open-source
\nstatic analysis tool for Android, found that 1,074 out
\nof 13,500 analyzed applications were improperly using
\ncryptographic certificates (41 of the 1,074 were manually verified) [122]. Similarly, SMV-Hunter [165], another open-source analysis tool for Android, found 1,453
\npotentially vulnerable apps using static analysis (726
\nof which were confirmed using dynamic analysis) to be
\nvulnerable to MitM attacks [155]. Moreover, numerous
\napplications (87.9% of the analyzed Android apps [156]
\nand 65.3% of analyzed iOS apps [157]) also have poorly
\nimplemented cryptographic constructs (e.g., using ECB
\nmode for encryption or hard-coded encryption keys),
\nwhich could expose private user data through relatively
\nsimple attacks.
\nExperiment While Google and Apple have since taken
\nsome steps to reduce the misuse of SSL\/TLS, as described in Section 3, they do not appear to have completely solved the problem. Our analysis of 50 recent
\nbanking applications (with both Android and iOS versions) found 4 apps on iOS and 2 apps on Android incorrectly validating SSL\/TLS certificates. In this work, we
\nwere using a Samsung Galaxy S6 and an iPhone 6s, both
\nwith the latest versions of the applications at the time
\nfor Android 5.1.1 and iOS 8.1.3. One noteworthy anecdote from our analysis suggests things are improving
\nhowever; one application had originally appeared vulnerable when analyzed statically, but before we could
\nanalyze the application dynamically it required an update that properly utilized TLS.
\n4.4.2 Privacy Policies
\nAs mentioned previously, privacy policies are used to
\ngovern an applications\u2019 use of private user data and
\nto inform users of how their data is being used. In
\nprincipal, these policies should enable users to make
\ninformed decisions about what applications to install,
\nbased on their privacy preferences. However, their efficacy is solely dependent on the users\u2019 ability to understand the information contained within these policies.
\nTo examine their effectiveness, we analyzed the privacy
\npolicies of the top 50 paid and top 50 free apps for Android and the top 100 paid and top 100 free apps for iOS
\n(56 unique Android policies and 126 unique iOS policies) for their readability using the Flesch Kincaid Grade
\nLeve (FKGL) [166]. Our results indicate that privacy
\npolicies on both Android and iOS, on average, require a
\ncollege reading level, and that very few of the policies,
\non either platform, were understandable at a high-school
\nreading level. Thus, while these policies are supposed to
\nserve as the primary tool for conveying privacy-related
\ninformation to users, they are likely incomprehensible
\nfor a large fraction of the population and, for the most
\npart, ineffective.
\nUnauthenticated
\nDownload Date | 7\/11\/17 1:00 AM
\nSoK: Privacy on Mobile Devices 110
\n4.5 A Data-Centric View
\nIt is also interesting to take a data-centric view of this
\nprivacy picture (i.e., the rows in Table 1). That is, for
\nspecific classes of data, to consider how this data can be
\naccessed and at what level of the platform.
\nThe first class of data that we examine are unique
\nidentifiers. These can be used to track users across services, applications, or devices potentially allowing a malicious party to learn a person\u2019s history through such
\nconnections. Note that such identifiers are accessible at
\nall levels of the stack. The different components of the
\nhardware layer are given this data as part of their operations. As our experiments showed, many types of identifiers can be accessed without any permissions, thus
\ngiving access to any applications or third-party libraries
\nthat may be installed on the device. Additionally, several works have shown how this private data can be
\naccessed by an eavesdropper or the MISP [108].
\nAnother interesting class of data to look at is location data, which is clearly very sensitive, as access
\nto it allows parties to locate and track the user of
\nthe mobile device. Unfortunately, a number of prior
\nworks [16, 42, 43, 56, 59, 104, 105, 113, 114] have shown
\nthat the picture here isn\u2019t much better. Location data
\nis largely available via various attacks and leakages for
\nmost devices across the different levels of the stack, revealing this private information to unintended parties.
\nFor instance, advertising libraries were able to obtain a
\nuser\u2019s location by appearing in an application with location permissions [33], MISPs can obtain a user\u2019s location
\nthrough normal operations [57], as can the BP and SIM.
\nIt was also recently shown that even a passive observer
\nis able to locate a particular user by intercepting unauthenticated communication with the MISP [28, 109].
\n4.6 Summary
\nAs this section shows, despite the many privacy protections employed, privacy leaks continue to persist on
\nmobile devices. This problem is exacerbated by the various channels, both explicit (i.e., user permissions) and
\nimplicit (i.e., a side-channel), that this data is accessible through. Subsequently, because the various parts of
\nthe mobile stack are built and controlled by different
\nproviders, this private data is accessible to a wide variety of parties. Furthermore, the abundance of sensors on
\nmobile devices leads to the collection and possible leakage of much more private data than would be available
\nin other computing environments. By examining the privacy gaps (both component-focused and data-focused)
\nat each level of the stack, we are able to appreciate the
\noverwhelming complexity that exists within these devices. To this end, while protecting user data that is explicitly exposed may be a tractable problem, a solution
\nthat is also able to protect data from the more implicit
\ninteractions will require significantly more effort.
\n5 A More Private Future
\nAs can be easily gleaned from our survey, the current
\nmobile-device ecosystem is extremely complex, with
\nmany components that are controlled by a variety of
\nparties. This complexity leads to a number of privacy leaks, which are not entirely addressed by existing
\nprivacy-preserving technology. In this section, we suggest a few possible research directions, aimed at reducing this complexity to improve mobile privacy. We note
\nthat our recommendations are very high-level and are
\nmeant to suggest broad research directions, rather than
\nprescribe specific solutions or guaranteed fixes.
\nReducing Trust Relationships One way to reduce
\nthe complexity of the mobile device ecosystem is to reduce the number of trust relationships that must be
\nestablished between the users and the various components of the ecosystem. One particularly promising way
\nto do this is through the use of advanced cryptographic
\ntechniques such as homomorphic encryption [167], secure multi-party computation [168, 169], and functional
\nencryption [170]. There are already surveys presenting
\nthe current state of these technologies (e.g., [171, 172]).
\nThese techniques would allow users to directly control
\nwho can access their private data and what they can do
\nwith it, without relying on any other privacy-preserving
\ncomponent to enforce these policies. While these techniques are all currently in the early research stages, we
\nbelieve that in the near future some of these technologies will make a major impact in this space.
\nOther ways to reduce these trust relationships include tools such as information flow control [102, 173],
\nsecure programming languages [174], and formal program verification [175]. Systems enforcing informationflow control (e.g., [176]) can ensure that sensitive data is
\nonly accessed by certain prescribed components, and in
\nappropriate ways, without requiring trust in these components. Similarly, secure programming languages and
\nprogram verification can be used to ensure that low-level
\nfirmware and applications are built in ways that do not
\nexpose significant privacy vulnerabilities.
\nUnauthenticated
\nDownload Date | 7\/11\/17 1:00 AM
\nSoK: Privacy on Mobile Devices 111
\nGuiding Users Toward Privacy In addition to reducing the number of trust relationships, there is a
\nneed to help end users make good privacy-related decisions to protect their own private data. For example,
\nboth Android and iOS currently prompt users when an
\napp would like to access specific data. However, it has
\nbeen shown that users generally do not understand the
\nimplications of these decisions [29, 92]. Several suggestions for helping users understand these decisions have
\nbeen proposed in the literature. Wang et al. [177] proposed adding purposes to permissions requests to inform users what their data will be used for, while Agarwal et al. [178] used crowdsourcing to help users determine which permissions were really necessary for a
\ngiven application. Another suggested approach aims to
\nhelp users by splitting permissions needed for the core
\napplication and any third-party libraries that these applications may include [179\u2013182], thus reducing any confusion as to which parties will be accessing the data.
\nMechanism Design for Privacy Finally, with all of
\nthe parties and complexity in the mobile ecosystem, we
\ncould use a self-regulating approach to preserving privacy. One such approach could be to leverage game theory, specifically the area of mechanism design to incentivize privacy-preserving behavior from selfish agents.
\nThis is similar (in principle) to how Bitcoin [183] encourages cooperation from its untrusted users. One suggestion to move toward such economic incentives would be
\nto impose financial punishments on culpable parties in
\ncase of a private-data leak, possibly also leveraging tools
\nsuch as data provenance to identify and punish all parties involved in collecting the leaked data. Alternative
\napproaches include setting up auctions for permissions
\nto collect user data, and allowing users to charge more
\nfor access to more-sensitive data. Of course a highly nontrivial part of this approach would be to identify parties
\nto enforce the penalties and rules of such mechanisms.
\nOne suggestion may be to leverage the Bitcoin crypto
\ncurrency to enforce such punishments without relying
\non any centralized trusted party as in the work on fair
\nexchange [184].
\n6 Conclusions
\nIn this work, we holistically analyzed the current mobile ecosystem and the impact that it is having on users
\nprivacy. Our analysis uncovered the overall complexity of these devices and the numerous parties associated with the components at each layer in the stack
\n(e.g., hardware, software, third-parties), each with their
\nown, sometimes conflicting, perspectives on user privacy. While many of these parties have taken significant
\nefforts to introduce protections for their individual components, these protections have not generally withstood
\nattack from the research community. In fact, data leakage has been found in every layer of the stack, compromising a wide variety of components, and in many cases
\nleveraging a vulnerability in one component to leak data
\nfrom another, otherwise protected, component. We thus
\ncodified how personal, environmental, and credentialing
\ndata are often de facto accessible to hardware, software,
\nand network providers that service the mobile phones,
\nmeaning that a privacy failure of any of these providers
\ncan lead to significant leakage of private data.
\nIn effect, our survey and experiments have demonstrated that, despite great efforts by companies with
\nexceptional resources, existing privacy-preserving technologies have fallen short of ensuring user privacy in
\nan age were unprecedented amounts of data about our
\nmost intimate moments has become available to our omnipresent mobile devices. We have argued that the main
\ncause for this failure has been the enormous complexity of the mobile device ecosystem with its multitude
\nof involved components and parties. In our view, the
\ncurrent approach, wherein each component attempts to
\nmanage its own privacy protections, will not ensure user
\nprivacy going forward. Instead, we believe a fundamentally different approach is needed, which expressly addresses the complexity and unique capabilities of this
\nmobile ecosystem. To this end, we have proposed several potential research directions, with the hope that
\nthey will eventually lead to a more private tomorrow.
\nAcknowledgments
\nWe would like to thank John Launchbury at DARPA for
\nmaking this entire project ( help with nursing paper writing from experts with MSN & DNP degrees) possible and our collaborators
\nat the RAND Corporation for their invaluable input.
\nThis material is based on work was sponsored by
\nDARPA under Air Force Contract #FA8721-05-C-0002
\nand in part on work supported by the National Science Foundation under Grant No. CNS-1012910. Any
\nopinions, findings, and conclusions or recommendations
\nexpressed in this material are those of the authors and
\ndo not necessarily reflect the view of DARPA or the
\nNational Science Foundation.
\nApproved for public release: distribution unlimited.
\nUnauthenticated
\nDownload Date | 7\/11\/17 1:00 AM
\nSoK: Privacy on Mobile Devices 112
\nReferences
\n[1] I. Leontiadis, C. Efstratiou, M. Picone, and C. Mascolo,
\n\u201cDon\u2019t kill my ads!: balancing privacy in an ad-supported
\nmobile application market,\u201d in MobiSys 2012.
\n[2] B. Ur, P. G. Leon, L. F. Cranor, R. Shay, and Y. Wang,
\n\u201cSmart, useful, scary, creepy: perceptions of online behavioral advertising,\u201d in SOUPS 2012.
\n[3] Z. Xu, K. Bai, and S. Zhu, \u201cTaplogger: Inferring user inputs on smartphone touchscreens using on-board motion
\nsensors,\u201d in WiSec 2012.
\n[4] L. Cai and H. Chen, \u201cTouchlogger: Inferring keystrokes on
\ntouch screen from smartphone motion.\u201d in HotSec 2011.
\n[5] P. Marquardt, A. Verma, H. Carter, and P. Traynor,
\n\u201c(sp)iphone: decoding vibrations from nearby keyboards
\nusing mobile phone accelerometers,\u201d in CCS 2011.
\n[6] J. Krumm and E. Horvitz, \u201cLOCADIO: Inferring motion
\nand location from Wi-Fi signal strengths,\u201d in MobiQuitous
\n2004.
\n[7] J. Han, E. Owusu, L. T. Nguyen, A. Perrig, and J. Zhang,
\n\u201cAccomplice: Location inference using accelerometers on
\nsmartphones,\u201d in COMSNETS 2012.
\n[8] Y. Michalevsky, G. Nakibly, A. Schulman, and D. Boneh,
\n\u201cPowerSpy: Location tracking using mobile device power
\nanalysis,\u201d in USENIX Sec. Symp. USENIX Association,
\n2015.
\n[9] M. Azizyan, I. Constandache, and R. Roy Choudhury, \u201cSurroundsense: mobile phone localization via ambience fingerprinting,\u201d in MobiCom 2009.
\n[10] Y. Michalevsky, D. Boneh, and G. Nakibly, \u201cGyrophone:
\nRecognizing speech from gyroscope signals,\u201d in USENIX
\nSec. Symp. USENIX Association, 2014.
\n[11] L. Sun, D. Zhang, B. Li, B. Guo, and S. Li, \u201cActivity
\nrecognition on an accelerometer embedded mobile phone
\nwith varying positions and orientations,\u201d in Ubiquitous intelligence and computing. Springer, 2010, pp. 548\u2013562.
\n[12] Qualcomm, \u201cHaven sec. platform,\u201d https:\/\/www.
\nqualcomm.com\/products\/snapdragon\/security.
\n[13] TrustKernel Team, Shanghai Pingbo Info Tech Co., Ltd.,
\n\u201cTrustkernel,\u201d https:\/\/www.trustkernel.com\/.
\n[14] J. Bennett, \u201cDevices with trustonic tee,\u201d https:\/\/www.
\ntrustonic.com\/news-events\/blog\/devices-trustonic-tee, 08
\n2015.
\n[15] S. Demetriou, W. Merrill, W. Yang, A. Zhang, and C. A.
\nGunter, \u201cFree for all! assessing user data exposure to advertising libraries on android,\u201d in NDSS 2016.
\n[16] I. Polakis, G. Argyros, T. Petsios, S. Sivakorn, and A. D.
\nKeromytis, \u201cWhere\u2019s wally?: Precise user discovery attacks
\nin location proximity services,\u201d in CCS 2015.
\n[17] C. Patsakis, A. Zigomitros, and A. Solanas, \u201cAnalysis of
\nprivacy and security exposure in mobile dating applications,\u201d in MSPN 2015.
\n[18] R. McCormick, \u201cHack leaks hundreds of nude celebrity
\nphotos,\u201d http:\/\/www.theverge.com\/2014\/9\/1\/6092089\/
\nnude-celebrity-hack, Sep. 2014.
\n[19] B. Krebs, \u201cThe target breach, by the numbers,\u201d Krebs on
\nSecurity, vol. 6, 2014.
\n[20] \u201cNewly disclosed N.S.A. files detail partnerships with
\nAT&T and Verizon,\u201d The New York Times, 2015.
\n[21] K. M. Sullivan, \u201cBut doctor, I still have both feet! Remedial problems faced by victims of medical identity theft,\u201d
\nAmerican Journal of Law & Medicine, vol. 35, no. 4, 2009.
\n[22] C. Apgar, G. Apple, L. Ayers, M. Berntsen, R. Busch,
\nJ. Childress, E. Curtis, N. Davis, M. Dawson, B. Hjort
\net al., \u201cMitigating medical identity theft,\u201d Journal of American Health Information Management Association, vol. 79,
\nno. 7, p. 63, 2008.
\n[23] C. J. Hoofnagle and J. M. Urban, \u201cAlan Westin\u2019s privacy
\nhomo economicus,\u201d Wake Forest Law Review, 2014.
\n[24] M. Madden and L. Rainie, \u201cAmericans\u2019 attitudes about privacy, sec. and surveillance,\u201d http:\/\/www.pewinternet.org\/
\n2015\/05\/20\/americans-attitudes-about-privacy-securityand-surveillance\/, May 2015.
\n[25] J. L. Boyles, A. Smith, and M. Madden, \u201cApps and privacy: More than half of app users have uninstalled or decided to not install an app due to concerns about their
\npersonal information,\u201d http:\/\/www.pewinternet.org\/2012\/
\n09\/05\/main-findings-7\/, Sep. 2015.
\n[26] Apple, \u201cWe\u2019ve given you tools to manage your privacy,\u201d
\nhttp:\/\/www.apple.com\/privacy\/manage-your-privacy\/,
\nRetrieved Nov. 2015.
\n[27] J. Han, Q. Yan, D. Gao, J. Zhou, and R. Deng, \u201cComparing mobile privacy protection through cross-platform
\napplications,\u201d in NDSS 2013.
\n[28] A. Shaik, R. Borgaonkar, N. Asokan, V. Niemi, and J.-P.
\nSeifert, \u201cPractical attacks against privacy and availability in
\n4G\/LTE mobile communication systems,\u201d in NDSS 2016.
\n[29] A. P. Felt, E. Ha, S. Egelman, A. Haney, E. Chin, and
\nD. Wagner, \u201cAndroid permissions: User attention, comprehension, and behavior,\u201d in SOUPS 2012.
\n[30] C. Xenakis and C. Ntantogian, \u201cAttacking the baseband
\nmodem of mobile phones to breach the users\u2019 privacy and
\nnetwork security,\u201d in CyCon 2015.
\n[31] Y. Zhou and X. Jiang, \u201cDissecting android malware: Characterization and evolution,\u201d in Proc. 2012 Symp. on Sec.
\nand Privacy. IEEE, 2012.
\n[32] L. Li, A. Bartel, T. F. D. A. Bissyande, J. Klein,
\nY. Le Traon, S. Arzt, S. Rasthofer, E. Bodden, D. Octeau,
\nand P. McDaniel, \u201cIccTA: Detecting inter-component privacy leaks in android apps,\u201d in ICSE 2015.
\n[33] M. C. Grace, W. Zhou, X. Jiang, and A.-R. Sadeghi, \u201cUnsafe exposure analysis of mobile in-app advertisements,\u201d in
\nWiSec 2012.
\n[34] P. McDaniel, \u201cBloatware comes to the smartphone,\u201d IEEE
\nSec. & Privacy 2012.
\n[35] W. Park, \u201cMobile phone addiction,\u201d Mobile Communications, 2005.
\n[36] C. Amrutkar, P. Traynor, and P. C. van Oorschot, \u201cAn
\nempirical Assessment of security indicators in mobile web
\nbrowsers,\u201d Transactions on Mobile Comp., vol. 14, no. 5,
\n2015.
\n[37] I. Paul, \u201cGoogle\u2019s new, highly targeted app ads react to
\nhow you use android apps,\u201d http:\/\/www.pcworld.com\/
\narticle\/2147001\/google-starts-using-your-android-appbehavior-to-deliver-highly-targeted-app-ads.html, 2015.
\n[38] Motorola, \u201cX8 mobile computing system,\u201d http:\/\/www.
\nmotorola.com\/us\/X8-Mobile-Computing-System\/x8-
\nmobile-computing-system.html.
\nUnauthenticated
\nDownload Date | 7\/11\/17 1:00 AM
\nSoK: Privacy on Mobile Devices 113
\n[39] Apple, \u201ciPhone 6s Technology,\u201d http:\/\/www.apple.com\/
\niphone-6s\/technology\/.
\n[40] R. Krten, \u201cGoogle android \u2013 IPC at the lowest levels,\u201d
\nhttp:\/\/www.embedded.com\/print\/4083262, June 2008.
\n[41] W. Rankl and W. Effing, \u201cSmart card security,\u201d Smart
\nCard Handbook, 4th Edition, pp. 667\u2013734, 2010.
\n[42] K. Koscher and E. Butler, \u201csimhacks,\u201d http:\/\/simhacks.
\ngithub.io\/.
\n[43] ETSI, \u201cSmart Cards; Card Application Toolket (Release
\n13),\u201d March 2015.
\n[44] Apple, \u201ciOS Security: iOS 9.0 or later,\u201d https:\/\/www.
\napple.com\/business\/docs\/iOS_Security_Guide.pdf, 2015.
\n[45] Google, \u201cGoogle history,\u201d https:\/\/history.google.com\/.
\n[46] C. Matyszczyk, \u201cTMI? Some fitbit users\u2019 sex stats on
\nGoogle search,\u201d http:\/\/www.cnet.com\/news\/tmi-somefitbit-users-sex-stats-on-google-search\/, Retrieved Nov.
\n2015.
\n[47] S. Son, D. Kim, and V. Shmatikov, \u201cWhat mobile ads
\nknow about mobile users,\u201d NDSS 2016.
\n[48] Gemalto, \u201cGemalto presents the findings of its investigations into the alleged hacking of sim card encryption keys
\nby britain\u2019s government communications headquarters and
\nthe U.S. National Security Agency,\u201d 2 2015.
\n[49] J. Zhang, F. Yuan, and Q. Xu, \u201cDeTrust: Defeating hardware trust verification with stealthy implicitly-triggered
\nhardware trojans,\u201d in CCS 2014.
\n[50] S. Wei and M. Potkonjak, \u201cThe undetectable and unprovable hardware trojan horse,\u201d in DAC 2013.
\n[51] T. Bray, \u201cExercising our remote application removal feature,\u201d http:\/\/android-developers.blogspot.com\/2010\/06\/
\nexercising-our-remote-application.html, June 2010.
\n[52] C. Beaumont, \u201cApple\u2019s Jobs confirms iPhone \u2018kill switch\u2019,\u201d
\nhttp:\/\/www.telegraph.co.uk\/technology\/3358134\/ApplesJobs-confirms-iPhone-kill-switch.html, Aug. 2008.
\n[53] Google, \u201cWhat data does Google collect?\u201d https:\/\/privacy.
\ngoogle.com\/data-we-collect.html.
\n[54] Trustonic, \u201cTrustonic,\u201d https:\/\/www.trustonic.com\/.
\n[55] Samsung, \u201cSamsung knox,\u201d http:\/\/www.samsungknox.
\ncom\/, Nov. 2015.
\n[56] R. Welton, \u201cRemote code execution as system user on
\nsamsung phones,\u201d https:\/\/www.nowsecure.com\/blog\/
\n2015\/06\/16\/remote-code-execution-as-system-user-onsamsung-phones\/, June 2015.
\n[57] ETSI, \u201c3G security; Lawful Interception; Stage 2 (3GPP
\nTS 43.033 version 12.0.0 Release 12),\u201d Oct. 2014.
\n[58] S. Gemplus, Oberthur, \u201cOver-the-air (OTA) technology,\u201d
\nftp:\/\/www.3gpp.org\/tsg_sa\/WG3_Security\/TSGS3_30_
\nPovoa\/Docs\/PDF\/S3-030534.pdf, Oct. 2010.
\n[59] J. Zang, K. Dummit, J. Graves, P. Lisker, and L. Sweeney,
\n\u201cWho knows what about me? A survey of behind the
\nscenes personal data sharing to third parties by mobile
\napps,\u201d http:\/\/techscience.org\/a\/2015103001\/, 2015.
\n[60] V. Woods and R. van der Meulen, \u201cGartner says emerging
\nmarkets drove worldwide smartphone sales to 15.5 percent
\ngrowth in third quarter of 2015,\u201d http:\/\/www.gartner.com\/
\nnewsroom\/id\/3169417, 2015.
\n[61] J.-E. Ekberg, K. Kostiainen, and N. Asokan, \u201cTrusted execution environments on mobile devices,\u201d in CCS 2013.
\n[62] ARM, \u201cARM Sec. Technology: Building a Secure System
\nusing TrustZone Technology,\u201d 2009.
\n[63] H. Lockheimer, \u201cHi, I\u2019m Hiroshi Lockheimer, here at
\nGoogle with the team that build Nexus 5X & 6P…Ask Us
\nAnything!\u201d https:\/\/www.reddit.com\/r\/IAmA\/comments\/
\n3mzrl9\/hi_im_hiroshi_lockheimer_here_at_google_with_
\nthe\/cvjj167, Oct. 2015.
\n[64] \u201cFull disk encryption,\u201d https:\/\/source.android.com\/
\nsecurity\/encryption\/, 2015.
\n[65] M. Broz, \u201cdm-crypt: Linux kernel device-mapper crypto
\ntarget,\u201d https:\/\/gitlab.com\/cryptsetup\/cryptsetup\/wikis\/
\nDMCrypt, 2015.
\n[66] J. Bonneau, \u201cA technical perspective on the apple iphone
\ncase,\u201d https:\/\/www.eff.org\/deeplinks\/2016\/02\/technicalperspective-apple-iphone-case, 2 2016.
\n[67] Statistica, \u201cNumber of apps available in leading app stores
\nas of july 2015,\u201d http:\/\/www.statista.com\/statistics\/
\n276623\/number-of-apps-available-in-leading-app-stores\/,
\nJuly 2015.
\n[68] A. P. Felt, M. Finifter, E. Chin, S. Hanna, and D. Wagner,
\n\u201cA survey of mobile malware in the wild,\u201d in SPSM 2011.
\n[69] Y. Zhou, Z. Wang, W. Zhou, and X. Jiang, \u201cHey, you, get
\noff of my market: Detecting malicious apps in official and
\nalternative android markets.\u201d in NDSS 2012.
\n[70] \u201cMobile Phone Spy Software,\u201d http:\/\/www.mobistealth.
\ncom\/mobile-phone-spy-software, 2015.
\n[71] M. Lindorfer, M. Neugschwandtner, L. Weichselbaum,
\nY. Fratantonio, V. van der Veen, and C. Platzer,
\n\u201cANDRUBIS-1,000,000 apps later: A view on current android malware behaviors,\u201d in BADGERS 2014.
\n[72] Claud Xiao, \u201cYiSpecter: First iOS Malware That Attacks
\nNon-jailbroken Apple iOS Devices by Abusing Private
\nAPIs,\u201d http:\/\/researchcenter.paloaltonetworks.com\/2015\/
\n10\/yispecter, 2015.
\n[73] Google, \u201cGoogle play,\u201d https:\/\/play.google.com\/.
\n[74] Amazon, \u201cAmazon appstore,\u201d http:\/\/www.amazon.com\/
\nmobile-apps\/b?node=2350149011.
\n[75] F. Cai, H. Chen, Y. Wu, and Y. Zhang, \u201cAppcracker:
\nWidespread vulnerabilities in user and session authentication in mobile apps,\u201d in MoST 2015.
\n[76] Google, \u201cGoogle play developer program policies,\u201d https:
\n\/\/play.google.com\/about\/developer-content-policy.html,
\n2015.
\n[77] Kim, Eunice, \u201cCreating better user experiences on google
\nplay,\u201d http:\/\/android-developers.blogspot.ro\/2015\/03\/
\ncreating-better-user-experiences-on.html, 2015.
\n[78] Google, \u201cAndroid security 2014 year in review,\u201d https:\/\/
\nstatic.googleusercontent.com\/media\/source.android.com\/
\nen\/\/security\/reports\/Google_Android_Security_2014_
\nReport_Final.pdf, 2014.
\n[79] Cluley, Graham, \u201cThe Hacking Team Android malware app
\nthat waltzed past Google Play\u2019s security checks,\u201d https:
\n\/\/heatsoftware.com\/security-blog\/10368\/the-hackingteam-android-malware-app-that-waltzed-past-googleplays-security-checks\/, 2015.
\n[80] J. Han, S. M. Kywe, Q. Yan, F. Bao, R. Deng, D. Gao,
\nY. Li, and J. Zhou, \u201cLaunching Generic Attacks on iOS
\nwith Approved Third-Party Appl.\u201d in Applied Cryptography
\nand Network Sec. Springer, 2013, pp. 272\u2013289.
\n[81] T. Wang, K. Lu, L. Lu, S. Chung, and W. Lee, \u201cJekyll
\non ios: When benign apps become evil,\u201d in USENIX Sec.
\nSymp. USENIX Association, 2013.
\nUnauthenticated
\nDownload Date | 7\/11\/17 1:00 AM
\nSoK: Privacy on Mobile Devices 114
\n[82] M. Bucicoiu, L. Davi, R. Deaconescu, and A.-R. Sadeghi,
\n\u201cXiOS: Extended application sandboxing on iOS,\u201d in ASIACCS 2015.
\n[83] Z. Deng, B. Saltaformaggio, X. Zhang, and D. Xu, \u201ciRiS:
\nVetting private API abuse in iOS applications,\u201d in CCS
\n2015.
\n[84] \u201cSystem and kernel security,\u201d https:\/\/source.android.com\/
\ndevices\/tech\/security\/overview\/kernel-security.html, 2015.
\n[85] \u201cSecurity-Enhanced Linux in Android,\u201d https:\/\/source.
\nandroid.com\/security\/selinux\/, 2015.
\n[86] D. Blazakis, \u201cThe apple sandbox,\u201d in Black Hat DC, 2011.
\n[87] D. A. Dai Zovi, \u201cApple iOS 4 security Assessment,\u201d https:\/\/
\nwww.trailofbits.com\/resources\/ios4_security_Assessment_
\npaper.pdf.
\n[88] S. Esser, \u201ciOS8 Containers, Sandboxes and Entitlements,\u201d
\nin Ruxcon, 2014.
\n[89] R. N. M. Watson, \u201cNew approaches to operating system
\nsecurity extensibility,\u201d University of Cambridge, Computer
\nLaboratory, Tech. Rep. UCAM-CL-TR-818, Apr. 2012.
\n[90] A. P. Felt, E. Chin, S. Hanna, D. Song, and D. Wagner,
\n\u201cAndroid permissions demystified,\u201d in CCS 2011.
\n[91] P. G. Kelley, S. Consolvo, L. F. Cranor, J. Jung, N. Sadeh,
\nand D. Wetherall, \u201cA conundrum of permissions: installing
\napplications on an android smartphone,\u201d in Proc. Financial
\nCryptography and Data Sec. Springer, 2012, pp. 68\u201379.
\n[92] J. Lin, S. Amini, J. I. Hong, N. Sadeh, J. Lindqvist, and
\nJ. Zhang, \u201cExpectation and purpose: understanding users\u2019
\nmental models of mobile app privacy through crowdsourcing,\u201d in Ubicomp 2012.
\n[93] \u201cAndroid 6.0 marshmallow,\u201d https:\/\/www.android.com\/
\nversions\/marshmallow-6-0\/, 2015.
\n[94] Apple Inc., \u201cAbout privacy and Location Services for iOS 8
\nand iOS 9,\u201d https:\/\/support.apple.com\/en-us\/HT203033,
\n2015.
\n[95] \u2014\u2014, \u201cEntitlement Key Reference,\u201d https:\/\/developer.
\napple.com\/library\/ios\/documentation\/Miscellaneous\/
\nReference\/EntitlementKeyReference\/Chapters\/
\nAboutEntitlements.html, 2014.
\n[96] \u201cUsing networking securely,\u201d https:\/\/developer.
\napple.com\/library\/prerelease\/ios\/documentation\/
\nNetworkingInternetWeb\/Conceptual\/NetworkingOverview\/
\nSecureNetworking\/SecureNetworking.html, 2015.
\n[97] \u201cSecurity with https and ssl,\u201d http:\/\/developer.android.
\ncom\/training\/articles\/security-ssl.html, 2015.
\n[98] \u201cSecurity enhancements in android 5.0,\u201d https:\/\/source.
\nandroid.com\/security\/enhancements\/enhancements50.html,
\n2015.
\n[99] \u201cWhat\u2019s new in iOS: iOS 9.0,\u201d https:\/\/developer.
\napple.com\/library\/prerelease\/ios\/releasenotes\/General\/
\nWhatsNewIniOS\/Articles\/iOS9.html#\/\/apple_ref\/doc\/
\nuid\/TP40016198-DontLinkElementID_13\/, 2015.
\n[100] \u201cApp Store Review Guidelines,\u201d https:\/\/developer.apple.
\ncom\/app-store\/review\/guidelines\/, 2015.
\n[101] \u201cGoogle Play Developer Distribution Agreement,\u201d https:\/\/
\nplay.google.com\/about\/developer-distribution-agreement.
\nhtml, 2015.
\n[102] L. Jia, J. Aljuraidan, E. Fragkaki, L. Bauer, M. Stroucken,
\nK. Fukushima, S. Kiyomoto, and Y. Miyake, \u201cRun-time
\nenforcement of information-flow properties on android,\u201d in
\nComputer Security \u2013 ESORICS 2013. Springer, 2013, pp.
\n775\u2013792.
\n[103] W. Enck, P. Gilbert, S. Han, V. Tendulkar, B.-G. Chun,
\nL. P. Cox, J. Jung, P. McDaniel, and A. N. Sheth, \u201cTaintdroid: an information-flow tracking system for realtime
\nprivacy monitoring on smartphones,\u201d TOCS 2014.
\n[104] T. M\u00fcller and M. Spreitzenbarth, \u201cFrost,\u201d in Applied Cryptography and Network Security. Springer, 2013, pp.
\n373\u2013388.
\n[105] J. Zdziarski, \u201cIdentifying back doors, attack points, and
\nsurveillance mechanisms in iOS devices,\u201d Digital Investigation, vol. 11, no. 1, pp. 3\u201319, 2014.
\n[106] U. D. of Justice, \u201cPakistani man indicted for selling stealthgenie spyware app,\u201d https:\/\/www.fbi.gov\/
\nwashingtondc\/press-releases\/2014\/pakistani-man-indictedfor-selling-stealthgenie-spyware-app, Sep. 2014.
\n[107] P. Coogan, \u201cAndroid rats branch out with dendroid,\u201d http:
\n\/\/www.symantec.com\/connect\/blogs\/android-rats-branchout-dendroid, March 2014.
\n[108] T. Chen, I. Ullah, M. A. Kaafar, and R. Boreli, \u201cInformation leakage through mobile analytics services,\u201d in HotMobile 2014.
\n[109] D. F. Kune, J. Koelndorfer, N. Hopper, and Y. Kim, \u201cLocation leaks on the GSM air interface,\u201d in NDSS 2012,
\n2012.
\n[110] D. Richardson, \u201cXcodeGhost iOS malware: The list of affected apps and what you should do,\u201d http:\/\/blog.lookout.
\ncom\/blog\/2015\/09\/21\/xcodeghost-apps\/, Sep. 2015.
\n[111] M. Zheng, H. Xue, Y. Zhang, T. Wei, and J. C. Lui, \u201cEnpublic apps: Security threats using iOS enterprise and developer certificates,\u201d in ASIACCS 2015.
\n[112] P. Paganini, \u201cSnooping Samsung S6 calls with bogus base
\nstations,\u201d http:\/\/securityaffairs.co\/wordpress\/41923\/
\nhacking\/snooping-samsung-s6.html, Nov. 2015.
\n[113] R.-P. Weinmann, \u201cBaseband attacks: Remote exploitation of memory corruptions in cellular protocol stacks.\u201d in
\nWOOT. USENIX Association, 2012.
\n[114] G. Qin, C. Patsakis, and M. Bouroche, \u201cPlaying hide and
\nseek with mobile dating applications,\u201d in ICT Sys. Sec. and
\nPrivacy Protection. Springer, 2014, pp. 185\u2013196.
\n[115] C. Miller, D. Blazakis, D. DaiZovi, S. Esser, V. Iozzo, and
\nR.-P. Weinmann, iOS Hacker\u2019s Handbook. John Wiley &
\nSons, 2012.
\n[116] D. Rosenberg, \u201cReflections on trusting trustzone,\u201d in
\nBlackhat, 2014.
\n[117] D. Shen, \u201cAttacking your trusted core: Exploiting trustzone
\non android,\u201d in Blackhat, 2015.
\n[118] laginimaineb, \u201cFull trustzone exploit for msm8974,\u201d http:
\n\/\/bits-please.blogspot.com\/2015\/08\/full-trustzone-exploitfor-msm8974.html, 2015.
\n[119] K. Nohl, \u201cRooting Sim Cards,\u201d in BlackHat Briefings, Las
\nVegas NV, July 2013.
\n[120] J. R. Rao, P. Rohatgi, H. Scherzer, and S. Tinguely, \u201cPartitioning attacks: or how to rapidly clone some GSM cards,\u201d
\nin Symp. on Sec. and Privacy. IEEE, 2002.
\n[121] J. Hubbard, K. Weimer, and Y. Chen, \u201cA study of SSL
\nproxy attacks on Android and iOS mobile applications,\u201d in
\nCCNC 2014.
\n[122] S. Fahl, M. Harbach, T. Muders, L. Baumg\u00e4rtner,
\nB. Freisleben, and M. Smith, \u201cWhy eve and mallory love
\nandroid: An analysis of android SSL (in)security,\u201d in CCS
\nUnauthenticated
\nDownload Date | 7\/11\/17 1:00 AM
\nSoK: Privacy on Mobile Devices 115
\n2012.
\n[123] S. Narain, A. Sanatinia, and G. Noubir, \u201cSingle-stroke
\nlanguage-agnostic keylogging using stereo-microphones
\nand domain specific machine learning,\u201d in WiSec 2014.
\n[124] R. Raguram, A. M. White, D. Goswami, F. Monrose, and
\nJ.-M. Frahm, \u201ciSpy: automatic reconstruction of typed
\ninput from compromising reflections,\u201d in CCS 2011.
\n[125] Y. Xu, J. Heinly, A. M. White, F. Monrose, and J.-M.
\nFrahm, \u201cSeeing double: Reconstructing obscured typed
\ninput from repeated compromising reflections,\u201d in CCS
\n2013.
\n[126] R.-P. Weinmann, \u201cNew challenges in baseband exploitation: The hexagon architecture,\u201d CODEGATE 2014.
\n[127] iPhone DevTeam, \u201cEvolution of the iPhone Baseband and Unlocks,\u201d http:\/\/old.sebug.net\/paper\/
\nMeeting-Documents\/hitbsecconf2012ams\/D1T2%20-
\n%20MuscleNerd%20-%20Evolution%20of%20iPhone%
\n20Baseband%20and%20Unlocks.pdf, May 2012.
\n[128] O. Dunkelman, N. Keller, and A. Shamir, \u201cA practical-time
\nattack on the A5\/3 cryptosystem used in third generation
\nGSM telephony,\u201d IACR Cryptology ePrint Archive, vol.
\n2010, p. 13, 2010.
\n[129] S. Beaupre, \u201cTrustnone,\u201d http:\/\/theroot.ninja\/disclosures\/
\nTRUSTNONE_1.0-11282015.pdf, 2015.
\n[130] Y. Gilad, A. Herzberg, and A. Trachtenberg, \u201cSecuring
\nsmartphones: A \u00b5tcb approach,\u201d Pervasive Comp., vol. 13,
\nno. 4, pp. 72\u201379, 2014.
\n[131] H. Chen, Y. Mao, X. Wang, D. Zhou, N. Zeldovich, and
\nM. F. Kaashoek, \u201cLinux kernel vulnerabilities: State-of-theart defenses and open problems,\u201d in APSys 2011.
\n[132] C. Spensky and H. Hu, \u201cLL-SmartCard,\u201d https:\/\/github.
\ncom\/mit-ll\/LL-Smartcard.
\n[133] G. Wilkinson, \u201cDigital terrestrial tracking: The future of
\nsurveillance,\u201d 2014.
\n[134] Eckhart, Trevor, \u201cCarrier IQ part 2,\u201d https:\/\/www.youtube.
\ncom\/watch?v=T17XQI_AYNo, 2011.
\n[135] N. Lee, \u201cSmartphones and privacy,\u201d in Facebook Nation.
\nSpringer, 2014, pp. 71\u201384.
\n[136] \u201cCVE-2014-8346.\u201d Available from MITRE, CVE-ID CVE2014-8346., Oct. 10 2014.
\n[137] G. Data, \u201cG data mobile malware report: Threat report
\nq2\/2015,\u201d https:\/\/public.gdatasoftware.com\/Presse\/
\nPublikationen\/Malware_Reports\/G_DATA_MobileMWR_
\nQ2_2015_EN.pdf, 2015.
\n[138] D. Gilbert, \u201cAmazon selling 40 dollar android tablets that
\ncome with pre-installed malware,\u201d http:\/\/www.ibtimes.
\ncom\/amazon-selling-40-android-tablets-come-pre-installedmalware-2181424, 2015.
\n[139] P. Kocialkowski, \u201cSamsung galaxy back-door,\u201d http:
\n\/\/redmine.replicant.us\/project ( help with nursing paper writing from experts with MSN & DNP degrees)s\/replicant\/wiki\/
\nSamsungGalaxyBackdoor, Februrary 2014.
\n[140] D. R. Thomas, A. R. Beresford, and A. Rice, \u201cSecurity
\nmetrics for the android ecosystem,\u201d in SPSM 2015.
\n[141] \u201cSystem permissions,\u201d http:\/\/developer.android.com\/
\nguide\/topic (sample nursing essay examples by the best nursing assignment writing service)s\/security\/permissions.html, 2015.
\n[142] SourceDNA, \u201ciOS apps caught using private APIs,\u201d https:
\n\/\/sourcedna.com\/blog\/20151018\/ios-apps-using-privateapis.html, 2015.
\n[143] Z. Chen, A. Mettler, P. Gilbert, and Y. Kang, \u201ciBackDoor:
\nHigh-Risk Code Hits iOS Apps,\u201d https:\/\/www.fireeye.com\/
\nblog\/threat-research\/2015\/11\/ibackdoor_high-risk.html,
\n2015.
\n[144] C. Xiao, \u201cWIRELURKER: A new era in iOS and OS X
\nmalware,\u201d https:\/\/www.paloaltonetworks.com\/content\/
\ndam\/paloaltonetworks-com\/en_US\/assets\/pdf\/reports\/
\nUnit_42\/unit42-wirelurker.pdf, 2015.
\n[145] J. Stewart, A. Trachtenberg, and A. Yerukhimovich, \u201cLook
\nma, no permissions! accessing private data on android,\u201d In
\nSubmission, 2016.
\n[146] A. M. White, A. R. Matthews, K. Z. Snow, and F. Monrose, \u201cPhonotactic reconstruction of encrypted VoIP conversations: Hookt on fon-iks,\u201d in Proc. Symp. on Sec. and
\nPrivacy. IEEE, 2011.
\n[147] C. V. Wright, L. Ballard, F. Monrose, and G. M. Masson,
\n\u201cLanguage identification of encrypted VoIP traffic: Alejandra y roberto or alice and bob?\u201d in USENIX Sec. Symp.
\nUSENIX Association, 2007.
\n[148] C. V. Wright, L. Ballard, S. E. Coull, F. Monrose, and
\nG. M. Masson, \u201cUncovering spoken phrases in encrypted
\nvoice over IP conversations,\u201d TISSEC 2010.
\n[149] K. P. Dyer, S. E. Coull, T. Ristenpart, and T. Shrimpton,
\n\u201cPeek-a-boo, i still see you: Why efficient traffic analysis countermeasures fail,\u201d in Symp. on Sec. and Privacy.
\nIEEE, 2012.
\n[150] R. Stevens, J. Ganz, V. Filkov, P. Devanbu, and H. Chen,
\n\u201cAsking for (and about) permissions used by android
\napps,\u201d in MSR 2013.
\n[151] X. Wei, L. Gomez, I. Neamtiu, and M. Faloutsos, \u201cPermission evolution in the android ecosystem,\u201d in ACSAC 2012.
\n[152] T. Book, A. Pridgen, and D. S. Wallach, \u201cLongitudinal
\nanalysis of android ad library permissions,\u201d in MoST 2013.
\n[153] M. Egele, C. Kruegel, E. Kirda, and G. Vigna, \u201cPiOS: Detecting privacy leaks in iOS applications,\u201d in NDSS 2011.
\n[154] C. Carmony, \u201cdm_dump,\u201d https:\/\/github.com\/c1fe\/dm_
\ndump\/, 2014.
\n[155] D. Sounthiraraj, J. Sahs, G. Greenwood, Z. Lin, and
\nL. Khan, \u201cSMV-Hunter: Large scale, automated detection
\nof SSL\/TLS man-in-the-middle vulnerabilities in android
\napps,\u201d in NDSS 2014.
\n[156] M. Egele, D. Brumley, Y. Fratantonio, and C. Kruegel,
\n\u201cAn empirical study of cryptographic misuse in android
\napplications,\u201d in CCS 2013, New York, NY, USA.
\n[157] Y. Li, Y. Zhang, J. Li, and D. Gu, \u201ciCryptoTracer: Dynamic analysis on misuse of cryptography functions in iOS
\nApplications,\u201d in Network and System Sec. Springer, 2014,
\npp. 349\u2013362.
\n[158] S. Fahl, M. Harbach, H. Perl, M. Koetter, and M. Smith,
\n\u201cRethinking SSL development in an appified world,\u201d in
\nCCS 2013.
\n[159] M. Georgiev, S. Iyengar, S. Jana, R. Anubhai, D. Boneh,
\nand V. Shmatikov, \u201cThe most dangerous code in the world:
\nvalidating SSL certificates in non-browser software,\u201d in
\nCCS 2012.
\n[160] L. Onwuzurike and E. De Cristofaro, \u201cDanger is my middle
\nname: experimenting with SSL vulnerabilities in android
\napps,\u201d in WiSec 2015.
\n[161] N. Vallina-Rodriguez, J. Amann, C. Kreibich, N. Weaver,
\nand V. Paxson, \u201cA tangled mass: The android root certificate stores,\u201d in CoNEXT 2014.
\nUnauthenticated
\nDownload Date | 7\/11\/17 1:00 AM
\nSoK: Privacy on Mobile Devices 116
\n[162] B. Reaves, N. Scaife, A. Bates, P. Traynor, and K. R.
\nButler, \u201cMo(bile) money, mo(bile) problems: analysis of
\nbranchless banking applications in the developing world,\u201d in
\nUSENIX Sec. Symp. USENIX Association, 2015.
\n[163] M. Oltrogge, Y. Acar, S. Dechand, M. Smith, and S. Fahl,
\n\u201cTo pin or not to pin? Helping app developers bullet proof
\ntheir TLS connections,\u201d in USENIX Sec. Symp. USENIX
\nAssociation, 2015.
\n[164] \u201cMallodroid,\u201d https:\/\/github.com\/sfahl\/mallodroid, 2015.
\n[165] \u201cSmv-hunter,\u201d https:\/\/github.com\/utds3lab\/SMVHunter,
\n2015.
\n[166] J. P. Kincaid, R. P. Fishburne Jr, R. L. Rogers, and B. S.
\nChissom, \u201cDerivation of new readability formulas (automated readability index, fog count and flesch reading ease
\nformula) for navy enlisted personnel,\u201d Naval Technical
\nTraining Command, Tech. Rep., 1975.
\n[167] C. Gentry, \u201cFully homomorphic encryption using ideal lattices,\u201d in STOC 2009.
\n[168] A. C. Yao, \u201cProtocols for secure computations (extended
\nabstract),\u201d in FOCS 1982.
\n[169] M. Ben-Or, S. Goldwasser, and A. Wigderson, \u201cCompleteness theorems for non-cryptographic fault-tolerant distributed computation (extended abstract),\u201d in STOC 1988.
\n[170] D. Boneh, A. Sahai, and B. Waters, \u201cFunctional encryption: Definitions and challenges,\u201d in TCC 2011.
\n[171] D. W. Archer, D. Bogdanov, B. Pinkas, and P. Pullonen,
\n\u201cMaturity and performance of programmable secure computation,\u201d IACR Cryptology ePrint Archive, vol. 2015, p.
\n1039, 2015.
\n[172] S. Yakoubov, V. Gadepally, N. Schear, E. Shen, and
\nA. Yerukhimovich, \u201cA survey of cryptographic approaches
\nto securing big-data analytics in the cloud,\u201d in HPEC 2014.
\n[173] J. Yang, K. Yessenov, and A. Solar-Lezama, \u201cA language
\nfor automatically enforcing privacy policies,\u201d in SIGPLAN
\nNotices, vol. 47, no. 1. ACM, 2012, pp. 85\u201396.
\n[174] A. Ruef and C. Rohlf, \u201cProgramming language theoretic
\nsec. in the real world: A mirage or the future?\u201d in Cyber
\nWarfare. Springer, 2015, pp. 307\u2013321.
\n[175] H. K. Harton, M. Sitaraman, and J. Krone, \u201cFormal program verification,\u201d Wiley Encyclopedia of Comp. Science
\nand Engineering, 2008.
\n[176] A. A. de Amorim, N. Collins, A. DeHon, D. Demange,
\nC. Hritcu, D. Pichardie, B. C. Pierce, R. Pollack, and
\nA. Tolmach, \u201cA verified information-flow architecture,\u201d
\nin POPL 2014.
\n[177] H. Wang, J. Hong, and Y. Guo, \u201cUsing text mining to infer
\nthe purpose of permission use in mobile apps,\u201d in UbiComp
\n2015.
\n[178] Y. Agarwal and M. Hall, \u201cProtectMyPrivacy: detecting and
\nmitigating privacy leaks on iOS devices using crowdsourcing,\u201d in MobiSys 2013.
\n[179] P. Pearce, A. P. Felt, G. Nunez, and D. Wagner, in ASIACCS 2012.
\n[180] S. Shekhar, M. Dietz, and D. S. Wallach, \u201cAdsplit: Separating smartphone advertising from applications,\u201d in
\nUSENIX Sec. Symp. USENIX Association, 2012.
\n[181] X. Zhang, A. Ahlawat, and W. Du, \u201cAframe: isolating advertisements from mobile applications in android,\u201d in ACSAC 2013.
\n[182] H. Kawabata, T. Isohara, K. Takemori, A. Kubota, J.-i.
\nKani, H. Agematsu, and M. Nishigaki, \u201cSanadbox: Sandboxing third party advertising libraries in a mobile application,\u201d in ICC 2013.
\n[183] S. Nakamoto, \u201cBitcoin: A peer-to-peer electronic cash
\nsystem,\u201d https:\/\/bitcoin.org\/bitcoin.pdf, 2011.
\n[184] R. Kumaresan, T. Moran, and I. Bentov, \u201cHow to use bitcoin to play decentralized poker,\u201d in CCS 2015.
\nUnauthenticated
\nDownload Date | 7\/11\/17 1:00 AM<\/p>\n","protected":false},"excerpt":{"rendered":"
Proceedings on Privacy Enhancing Technologies ; 2016 (3):96\u2013116 Chad Spensky, Jeffrey Stewart, Arkady Yerukhimovich, Richard Shay, Ari Trachtenberg, Rick Housley, and Robert K. Cunningham SoK:\u2026<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7316,7318,7317,7315,7319,7321],"tags":[441,7323,628,7326,7325,7322,7324],"class_list":["post-49182","post","type-post","status-publish","format-standard","hentry","category-best-dissertation-writers-uk","category-british-dissertation-writers","category-dissertation-help-online","category-dissertation-writing-services-uk","category-help-with-dissertation-writing","category-uk-dissertation-help","tag-cheap-dissertation-writing-services","tag-dissertation-help-london","tag-dissertation-help-online","tag-dissertation-tutor","tag-expert-assignment-help","tag-masters-dissertation-help","tag-university-assignment-help"],"_links":{"self":[{"href":"https:\/\/www.studyproessays.com\/help\/wp-json\/wp\/v2\/posts\/49182","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.studyproessays.com\/help\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.studyproessays.com\/help\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.studyproessays.com\/help\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.studyproessays.com\/help\/wp-json\/wp\/v2\/comments?post=49182"}],"version-history":[{"count":0,"href":"https:\/\/www.studyproessays.com\/help\/wp-json\/wp\/v2\/posts\/49182\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.studyproessays.com\/help\/wp-json\/wp\/v2\/media?parent=49182"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.studyproessays.com\/help\/wp-json\/wp\/v2\/categories?post=49182"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.studyproessays.com\/help\/wp-json\/wp\/v2\/tags?post=49182"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}