25-08-2017, 09:32 PM
Defending Against Sensor-Sniffing Attacks on Mobile
[attachment=24096]
ABSTRACT
Modern mobile phones possess three types of capabilities:
computing, communication, and sensing. While these capabilities
enable a variety of novel applications, they also raise
serious privacy concerns. We explore the vulnerability where
attackers snoop on users by sniffing on their mobile phone
sensors, such as the microphone, camera, and GPS receiver.
We show that current mobile phone platforms inadequately
protect their users from this threat. To provide better privacy
for mobile phone users, we analyze desirable uses of
these sensors and discuss the properties of good privacy protection
solutions. Then, we propose a general framework for
such solutions and discuss various possible approaches to
implement the framework’s components.
Categories and Subject Descriptors
D.4.6 [Operating Systems]: Security and Protection—Access
controls, Information flow controls, Invasive software
General Terms
Design, Security, Human Factors
Keywords
privacy, mobile, sensor, sniffing, microphone
1. INTRODUCTION
Unlike mobile devices in the past, which were designed
for the sole purpose of voice-based communication, today’s
phones are powerful devices that can communicate, compute,
and sense. The sensing capabilities of mobile phones
come from the audio, video, and location sensors in the form
of microphones, cameras, and GPS receivers. While these
sensors enable a variety of new applications, they can also
seriously jeopardize user privacy. In particular, if a mobile
device is compromised, an adversary can not only access the
data stored in the device but also record all of the user’s
actions by stealthily sniffing on the sensors.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
MobiHeld’09, August 17, 2009, Barcelona, Spain.
Copyright 2009 ACM 978-1-60558-444-7/09/08 ...$10.00.
We focus on threats to users’ privacy due to unauthorized
sniffing on mobile phone sensors. These threats are different
from the more traditional attacks on user privacy on
PCs. Those attacks aim at (1) accessing private data or (2)
eavesdropping on users’ operations (e.g., key loggers). The
first type of attacks can be defeated by proper file access
control policies or encryption. The second type of attacks
is effective only when the user is interacting with his PC.
In contrast, appropriate access control on sensors often depends
on the context, so a static access control policy with
no regard to the context, which is typical on file systems,
is inadequate. Also, these attacks work even when the user
is not interacting with the mobile phone. As long as the
phone is within the proximity of the user, which is often
the case, the attacker can continuously snoop on the user’s
activities. Such snooping can also help attackers compromise
other computing devices. For example, the attacker
can listen to the acoustics of the keyboard to infer typed
passwords [1].
Although PCs can also be equipped with sensors, the
sensor-sniffing problem is much more serious on mobile devices.
On PCs, most sensors are optional, add-on peripherals.
They are not universally available, are not used by
most applications, and can be turned off without affecting
most tasks. In contrast, microphones are universally available
and indispensable on all mobile phones; cameras and
GPS receivers are moving in this direction as well. Mobile
applications use and depend on sensors more extensively.
Moreover, users tend to carry mobile devices wherever they
go. Hence, sensor-sniffing attackers have many more opportunities
to compromise the privacy of mobile users than PC
users.
Prior work has raises privacy concerns about mobile phone
sensors, primarily in the context of location sensing where
location is either read from GPS sensors in mobile phones
or inferred from other sources such as nearby cells [2, 3].
Solutions to mitigate this problem have mainly focused on
defining security policies [4, 5] or privacy rules [6]. Some
commercial software allows tracking employees and children
[7, 8]. To our knowledge, there has been little focus on the
other sensors (particularly microphones and cameras, which
are arguably the most important sensors) on mobile phones
except for scattered reports in non-scientific literature [9].
We start our exploration of sensor-sniffing attacks by developing
an appropriate threat model. Under this threat
model, we show that current mobile phone platforms inadequately
protect users. We use existing applications to understand
and classify legitimate uses of sensors. The complexity
31
and diversity of such uses pose significant challenges in developing
a single mechanism to detect unauthorized sensor
sniffers. Instead, we develop a general solution framework
and describe how we could implement its various components.
We take advantage of various unique properties of
the mobile platform to design novel mechanisms for these
components. For instance, we could use the context inferred
from sensors to enforce context-aware access control policies.
Our contributions are threefold. First, we examine the
privacy implications of powerful sensing capabilities in mobile
phones. Second, we demonstrate the significant challenges
in alleviating the sensor-sniffing problem. Third, we
develop a general framework for preserving privacy and identify
a few promising first-cut approaches for its components.
Even though we are far from achieving a complete privacypreserving
solution for mobile phones, our work aims at
spurring further research into this important area. The continued
popularity of mobile phones will be seriously jeopardized
if users start to view them as untrustworthy.
2. PROBLEM SCOPE
2.1 Problem Definition
We consider attacks that violate user privacy by sniffing
on the sensors on mobile phones. Typical sensors include
the microphone, camera, and GPS receiver.1 Focusing on
these sensors, particularly microphone and camera, we illustrate
that sensor-sniffing attacks pose challenges that are
quite different from those posed by general malware. We
also do not consider attacks that sniff on traditional input
devices, such as the keyboard and mouse. The reason is that
these attacks have been investigated extensively on desktop
computers, and we expect the defenses developed apply to
mobile phones as well. We also do not consider attacks that
steal confidential files for the same reason as above.
2.2 Threat Model
We define the threat model of sensor-sniffing attacks as
follows. The threat model defines the capabilities of attackers,
which are necessary for evaluating our proposed solutions.
• We assume that attackers are able to install malicious
software on mobile devices. The attackers can achieve
this by exploiting software vulnerabilities (e.g., driveby
download) or tricking users into installing untrusted
code.
• We assume that attackers have no physical access to
the compromised mobile devices and can receive the
captured sensor data only via voice or data channels,
such as outgoing phone calls, SMS, MMS, and TCP
connections.
• When we investigate defense approaches, we will discuss
how to implement the defense mechanisms in the
operating system, on the assumption that attackers
cannot compromise the operating system. However,
1Other possible sensors on mobile phones include accelerometers,
which are increasingly popular, and other more esoteric
sensors, such as thermometers and barometers. Attackers
can sniff on these sensors to violate users’ privacy as
well. However, for a focused discussion, we target the most
prevalent sensors today — microphone, camera, and GPS.
this assumption is not a fundamental requirement of
our approach. If the operating system is vulnerable,
we could move the defense mechanisms into the virtual
machine monitor where available or the firmware.
3. CURRENT USES AND PROTECTIONOF SENSORS
In this section, we describe how legitimate applications
use mobile phone sensors in different ways and why they
can complicate protection mechanisms. Then, we show that
popular smart phones protect their sensors inadequately.
3.1 How Applications Use Sensors
To prevent malicious use of sensors, we need to understand
how legitimate applications may use sensors. We classify
legitimate uses of sensors into three categories, based on
how prominent a role sensors play in the applications.
3.1.1 Dominated by Sensors
In this category, the main function of the application is
to capture the input of the sensor. For example, the microphone
provides input to the telephony, VoIP, and voice
recorder applications; the camera provides input to photo
and video capture applications. Such an application turns
on a sensor at start up and turns it off at completion. The
user is aware that the application is using the sensor continuously.
3.1.2 Supported by Sensors
In this category, sensors provide auxiliary input to applications,
but the main function of the application is not to
capture sensor input. For instance, a voice-dialing application
reads the user’s voice from the microphone, recognizes
the phone number, and then dials the number. [10] uses
camera-equipped mobile phones to interact with real-world
objects. Some applications may also send the captured data
back to a remote server. For example, the Android application
CompareEverywhere[11] can capture the barcode image
of a product and compare its price with those in nearby
stores using an online database. In these cases, the application
need not turn on the sensor throughout its lifetime,
but the user knows when the sensing starts and ends.
3.1.3 Using Context Provided by Sensors
In the previous two categories, the user initiates the sensing
by the applications. By contrast, context-aware computing
[12, 13] automatically detects the user’s context by
sensing continuously. For example, [14] proposes to use the
camera as a light sensor. [15] describes how to use the microphone
to detect the ambient noise level to adjust the ringer
volume accordingly. Recently, [16] demonstrated how to infer
the distance of two smart phones using their speakers
and microphones. In all these applications, sensors provide
contextual information specific to the environment. As such,
users may not be aware that the sensor is recording continuously.
3.2 Why a Hardware Switch Won’tWork
One might propose a simple hardware switch to turn on
and off sensors. It might work well with the first category
of applications. Since they turn on the sensors throughout
their lifetime, we could combine the hardware switch with
32
the buttons that start the applications. The advantage of
this solution is that no extra work is required from users.
However, this approach does not work well with the second
category of applications. Since the sensor need not be
turned on throughout the application’s lifetime, the hardware
switch cannot be combined with the application-start
buttons. Therefore, the phone would need extra buttons.
Moreover, it requires extra work from the user – e.g., switching
on the microphone to start voice-dialing and switching
it off when he is finished – which can be annoying. Finally,
it would be infeasible to design a hardware sensor switch
for the third category of applications, since they require the
sensors to remain on at all times.
3.3 Limitations of Current Systems
Current mobile operating systems, such as Windows Mobile[
17], Symbian[18], BlackBerry[19], and Google Android[20],
provide certain mechanisms for protecting sensors, but these
mechanisms are inadequate.
Certification: Among today’s systems, the most widelyused
security solutions are based on certification. These solutions
encourage users to install and use applications only
if they have been certified by a trusted source. Although
widely adopted by mainstream mobile platforms, the limitations
of certification are obvious: (1) It merely raises the
bar for malware developers without providing real security
assurance. Moveover, even if the certification authority can
verify that an application satisfies its privacy policy, its privacy
policy may differ significantly from the user’s desirable
policy. (2) Certification can be circumvented when users are
tricked into installing malware bundled with an otherwise
compelling application such as a game. (3) Applications
are often certified based on organizational trust relationship
rather than technical verification.
Reference Architecture: Reference architectures[21, 22]
apply traditional OS security mechanisms — such as sandboxing,
run-time monitoring, and integrity verification —
to the mobile platform. For example, Google Android requires
each application to list all the privileges that it needs
(including accessing hardware and network connection) in a
manifest file and detects any violations in runtime. However,
this does not solve the sensor-sniffing problem because
it continues to rely on user knowledge and diligence
to grant/deny access.
To help us understand the ease of writing sensor-sniffers,
we experimented with one of the above mobile platforms.
We used a mobile smartphone with built-in Assisted GPS
module and a 2.0 megapixel camera. We easily developed a
program that periodically records 30 seconds of sound, takes
a picture, and reads location information from the GPS.
The program stores the recorded data in a file and later
uploads it to an FTP server. The phone notifies the user of
this program’s activities only when the program dials up to
establish a network connection. However, the program could
avoid suspicion by waiting for another program to establish
a network connection and then using that connection to send
out the recorded data.
Recent work [23] has also shown the feasibility of sniffing
the video sensor by building a video capture malware with
specific trigger algorithm and infection methods. It shows
that such malware can be implemented with limited use of
power, CPU, and memory, thereby making detection hard
as well.
4. DESIGN OF A DEFENSE SYSTEM
Given the variety of ways in which legitimate applications
can use sensors, we believe that a single solution cannot
be a complete defense. Instead, we believe that a general
framework that can accommodate several design choices is
more appropriate. Before we present the framework and its
key components, we first discuss the properties desired for
an ideal solution.
4.1 Desirable Properties
An ideal solution must reliably prevent malicious programs
from sniffing phone sensors without imposing unacceptable
burdens on users. Specifically, it must possess the
following properties:
• Security: The solution must be able to prevent malicious
programs from reliably accessing protected sensors.
• Usability: Ideally, the solution should require no user
intervention. This way, the security solution incurs
no usability cost to the user. If user intervention is
unavoidable, the user should be able to make informed
security decisions and should not have to make such
decisions too often. The decisions should not disrupt
the user’s work flow.
• Backward and Forward Compatibility: The solution
should require no or minimal modification to existing
applications. Existing applications that access
sensors should continue functioning. Since we cannot
predict future applications, we should also avoid restricting
how future applications may use the sensors.
Therefore, the solution should allow diverse ways of
using the sensors.
• Performance: The solution should have small overhead
and should not considerably degrade the performance
of the OS or applications.
• Versatility: Mobile devices have a plethora of hardware,
software, and user interfaces. The solution should
apply to these various devices.
[attachment=24096]
ABSTRACT
Modern mobile phones possess three types of capabilities:
computing, communication, and sensing. While these capabilities
enable a variety of novel applications, they also raise
serious privacy concerns. We explore the vulnerability where
attackers snoop on users by sniffing on their mobile phone
sensors, such as the microphone, camera, and GPS receiver.
We show that current mobile phone platforms inadequately
protect their users from this threat. To provide better privacy
for mobile phone users, we analyze desirable uses of
these sensors and discuss the properties of good privacy protection
solutions. Then, we propose a general framework for
such solutions and discuss various possible approaches to
implement the framework’s components.
Categories and Subject Descriptors
D.4.6 [Operating Systems]: Security and Protection—Access
controls, Information flow controls, Invasive software
General Terms
Design, Security, Human Factors
Keywords
privacy, mobile, sensor, sniffing, microphone
1. INTRODUCTION
Unlike mobile devices in the past, which were designed
for the sole purpose of voice-based communication, today’s
phones are powerful devices that can communicate, compute,
and sense. The sensing capabilities of mobile phones
come from the audio, video, and location sensors in the form
of microphones, cameras, and GPS receivers. While these
sensors enable a variety of new applications, they can also
seriously jeopardize user privacy. In particular, if a mobile
device is compromised, an adversary can not only access the
data stored in the device but also record all of the user’s
actions by stealthily sniffing on the sensors.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
MobiHeld’09, August 17, 2009, Barcelona, Spain.
Copyright 2009 ACM 978-1-60558-444-7/09/08 ...$10.00.
We focus on threats to users’ privacy due to unauthorized
sniffing on mobile phone sensors. These threats are different
from the more traditional attacks on user privacy on
PCs. Those attacks aim at (1) accessing private data or (2)
eavesdropping on users’ operations (e.g., key loggers). The
first type of attacks can be defeated by proper file access
control policies or encryption. The second type of attacks
is effective only when the user is interacting with his PC.
In contrast, appropriate access control on sensors often depends
on the context, so a static access control policy with
no regard to the context, which is typical on file systems,
is inadequate. Also, these attacks work even when the user
is not interacting with the mobile phone. As long as the
phone is within the proximity of the user, which is often
the case, the attacker can continuously snoop on the user’s
activities. Such snooping can also help attackers compromise
other computing devices. For example, the attacker
can listen to the acoustics of the keyboard to infer typed
passwords [1].
Although PCs can also be equipped with sensors, the
sensor-sniffing problem is much more serious on mobile devices.
On PCs, most sensors are optional, add-on peripherals.
They are not universally available, are not used by
most applications, and can be turned off without affecting
most tasks. In contrast, microphones are universally available
and indispensable on all mobile phones; cameras and
GPS receivers are moving in this direction as well. Mobile
applications use and depend on sensors more extensively.
Moreover, users tend to carry mobile devices wherever they
go. Hence, sensor-sniffing attackers have many more opportunities
to compromise the privacy of mobile users than PC
users.
Prior work has raises privacy concerns about mobile phone
sensors, primarily in the context of location sensing where
location is either read from GPS sensors in mobile phones
or inferred from other sources such as nearby cells [2, 3].
Solutions to mitigate this problem have mainly focused on
defining security policies [4, 5] or privacy rules [6]. Some
commercial software allows tracking employees and children
[7, 8]. To our knowledge, there has been little focus on the
other sensors (particularly microphones and cameras, which
are arguably the most important sensors) on mobile phones
except for scattered reports in non-scientific literature [9].
We start our exploration of sensor-sniffing attacks by developing
an appropriate threat model. Under this threat
model, we show that current mobile phone platforms inadequately
protect users. We use existing applications to understand
and classify legitimate uses of sensors. The complexity
31
and diversity of such uses pose significant challenges in developing
a single mechanism to detect unauthorized sensor
sniffers. Instead, we develop a general solution framework
and describe how we could implement its various components.
We take advantage of various unique properties of
the mobile platform to design novel mechanisms for these
components. For instance, we could use the context inferred
from sensors to enforce context-aware access control policies.
Our contributions are threefold. First, we examine the
privacy implications of powerful sensing capabilities in mobile
phones. Second, we demonstrate the significant challenges
in alleviating the sensor-sniffing problem. Third, we
develop a general framework for preserving privacy and identify
a few promising first-cut approaches for its components.
Even though we are far from achieving a complete privacypreserving
solution for mobile phones, our work aims at
spurring further research into this important area. The continued
popularity of mobile phones will be seriously jeopardized
if users start to view them as untrustworthy.
2. PROBLEM SCOPE
2.1 Problem Definition
We consider attacks that violate user privacy by sniffing
on the sensors on mobile phones. Typical sensors include
the microphone, camera, and GPS receiver.1 Focusing on
these sensors, particularly microphone and camera, we illustrate
that sensor-sniffing attacks pose challenges that are
quite different from those posed by general malware. We
also do not consider attacks that sniff on traditional input
devices, such as the keyboard and mouse. The reason is that
these attacks have been investigated extensively on desktop
computers, and we expect the defenses developed apply to
mobile phones as well. We also do not consider attacks that
steal confidential files for the same reason as above.
2.2 Threat Model
We define the threat model of sensor-sniffing attacks as
follows. The threat model defines the capabilities of attackers,
which are necessary for evaluating our proposed solutions.
• We assume that attackers are able to install malicious
software on mobile devices. The attackers can achieve
this by exploiting software vulnerabilities (e.g., driveby
download) or tricking users into installing untrusted
code.
• We assume that attackers have no physical access to
the compromised mobile devices and can receive the
captured sensor data only via voice or data channels,
such as outgoing phone calls, SMS, MMS, and TCP
connections.
• When we investigate defense approaches, we will discuss
how to implement the defense mechanisms in the
operating system, on the assumption that attackers
cannot compromise the operating system. However,
1Other possible sensors on mobile phones include accelerometers,
which are increasingly popular, and other more esoteric
sensors, such as thermometers and barometers. Attackers
can sniff on these sensors to violate users’ privacy as
well. However, for a focused discussion, we target the most
prevalent sensors today — microphone, camera, and GPS.
this assumption is not a fundamental requirement of
our approach. If the operating system is vulnerable,
we could move the defense mechanisms into the virtual
machine monitor where available or the firmware.
3. CURRENT USES AND PROTECTIONOF SENSORS
In this section, we describe how legitimate applications
use mobile phone sensors in different ways and why they
can complicate protection mechanisms. Then, we show that
popular smart phones protect their sensors inadequately.
3.1 How Applications Use Sensors
To prevent malicious use of sensors, we need to understand
how legitimate applications may use sensors. We classify
legitimate uses of sensors into three categories, based on
how prominent a role sensors play in the applications.
3.1.1 Dominated by Sensors
In this category, the main function of the application is
to capture the input of the sensor. For example, the microphone
provides input to the telephony, VoIP, and voice
recorder applications; the camera provides input to photo
and video capture applications. Such an application turns
on a sensor at start up and turns it off at completion. The
user is aware that the application is using the sensor continuously.
3.1.2 Supported by Sensors
In this category, sensors provide auxiliary input to applications,
but the main function of the application is not to
capture sensor input. For instance, a voice-dialing application
reads the user’s voice from the microphone, recognizes
the phone number, and then dials the number. [10] uses
camera-equipped mobile phones to interact with real-world
objects. Some applications may also send the captured data
back to a remote server. For example, the Android application
CompareEverywhere[11] can capture the barcode image
of a product and compare its price with those in nearby
stores using an online database. In these cases, the application
need not turn on the sensor throughout its lifetime,
but the user knows when the sensing starts and ends.
3.1.3 Using Context Provided by Sensors
In the previous two categories, the user initiates the sensing
by the applications. By contrast, context-aware computing
[12, 13] automatically detects the user’s context by
sensing continuously. For example, [14] proposes to use the
camera as a light sensor. [15] describes how to use the microphone
to detect the ambient noise level to adjust the ringer
volume accordingly. Recently, [16] demonstrated how to infer
the distance of two smart phones using their speakers
and microphones. In all these applications, sensors provide
contextual information specific to the environment. As such,
users may not be aware that the sensor is recording continuously.
3.2 Why a Hardware Switch Won’tWork
One might propose a simple hardware switch to turn on
and off sensors. It might work well with the first category
of applications. Since they turn on the sensors throughout
their lifetime, we could combine the hardware switch with
32
the buttons that start the applications. The advantage of
this solution is that no extra work is required from users.
However, this approach does not work well with the second
category of applications. Since the sensor need not be
turned on throughout the application’s lifetime, the hardware
switch cannot be combined with the application-start
buttons. Therefore, the phone would need extra buttons.
Moreover, it requires extra work from the user – e.g., switching
on the microphone to start voice-dialing and switching
it off when he is finished – which can be annoying. Finally,
it would be infeasible to design a hardware sensor switch
for the third category of applications, since they require the
sensors to remain on at all times.
3.3 Limitations of Current Systems
Current mobile operating systems, such as Windows Mobile[
17], Symbian[18], BlackBerry[19], and Google Android[20],
provide certain mechanisms for protecting sensors, but these
mechanisms are inadequate.
Certification: Among today’s systems, the most widelyused
security solutions are based on certification. These solutions
encourage users to install and use applications only
if they have been certified by a trusted source. Although
widely adopted by mainstream mobile platforms, the limitations
of certification are obvious: (1) It merely raises the
bar for malware developers without providing real security
assurance. Moveover, even if the certification authority can
verify that an application satisfies its privacy policy, its privacy
policy may differ significantly from the user’s desirable
policy. (2) Certification can be circumvented when users are
tricked into installing malware bundled with an otherwise
compelling application such as a game. (3) Applications
are often certified based on organizational trust relationship
rather than technical verification.
Reference Architecture: Reference architectures[21, 22]
apply traditional OS security mechanisms — such as sandboxing,
run-time monitoring, and integrity verification —
to the mobile platform. For example, Google Android requires
each application to list all the privileges that it needs
(including accessing hardware and network connection) in a
manifest file and detects any violations in runtime. However,
this does not solve the sensor-sniffing problem because
it continues to rely on user knowledge and diligence
to grant/deny access.
To help us understand the ease of writing sensor-sniffers,
we experimented with one of the above mobile platforms.
We used a mobile smartphone with built-in Assisted GPS
module and a 2.0 megapixel camera. We easily developed a
program that periodically records 30 seconds of sound, takes
a picture, and reads location information from the GPS.
The program stores the recorded data in a file and later
uploads it to an FTP server. The phone notifies the user of
this program’s activities only when the program dials up to
establish a network connection. However, the program could
avoid suspicion by waiting for another program to establish
a network connection and then using that connection to send
out the recorded data.
Recent work [23] has also shown the feasibility of sniffing
the video sensor by building a video capture malware with
specific trigger algorithm and infection methods. It shows
that such malware can be implemented with limited use of
power, CPU, and memory, thereby making detection hard
as well.
4. DESIGN OF A DEFENSE SYSTEM
Given the variety of ways in which legitimate applications
can use sensors, we believe that a single solution cannot
be a complete defense. Instead, we believe that a general
framework that can accommodate several design choices is
more appropriate. Before we present the framework and its
key components, we first discuss the properties desired for
an ideal solution.
4.1 Desirable Properties
An ideal solution must reliably prevent malicious programs
from sniffing phone sensors without imposing unacceptable
burdens on users. Specifically, it must possess the
following properties:
• Security: The solution must be able to prevent malicious
programs from reliably accessing protected sensors.
• Usability: Ideally, the solution should require no user
intervention. This way, the security solution incurs
no usability cost to the user. If user intervention is
unavoidable, the user should be able to make informed
security decisions and should not have to make such
decisions too often. The decisions should not disrupt
the user’s work flow.
• Backward and Forward Compatibility: The solution
should require no or minimal modification to existing
applications. Existing applications that access
sensors should continue functioning. Since we cannot
predict future applications, we should also avoid restricting
how future applications may use the sensors.
Therefore, the solution should allow diverse ways of
using the sensors.
• Performance: The solution should have small overhead
and should not considerably degrade the performance
of the OS or applications.
• Versatility: Mobile devices have a plethora of hardware,
software, and user interfaces. The solution should
apply to these various devices.