Journal:What is this sensor and does this app need access to it?
Full article title | What is this sensor and does this app need access to it? |
---|---|
Journal | Informatics |
Author(s) | Mehrnezhad, Maaryam; Toreini, Ehsan |
Author affiliation(s) | Newcastle University |
Primary contact | Email: maryam dot mehrnezhad at ncl dot ac dot uk |
Year published | 2019 |
Volume and issue | 6(1) |
Page(s) | 7 |
DOI | 10.3390/informatics6010007 |
ISSN | 2227-9709 |
Distribution license | Creative Commons Attribution 4.0 International |
Website | https://www.mdpi.com/2227-9709/6/1/7/htm |
Download | https://www.mdpi.com/2227-9709/6/1/7/pdf (PDF) |
This article should be considered a work in progress and incomplete. Consider this article incomplete until this notice is removed. |
Abstract
Mobile sensors have already proven to be helpful in different aspects of people’s everyday lives such as fitness, gaming, navigation, etc. However, illegitimate access to these sensors results in a malicious program running with an exploit path. While users are benefiting from richer and more personalized apps, the growing number of sensors introduces new security and privacy risks to end-users and makes the task of sensor management more complex. In this paper, we first discuss the issues around the security and privacy of mobile sensors. We investigate the available sensors on mainstream mobile devices and study the permission policies that Android, iOS and mobile web browsers offer for them. Second, we reflect on the results of two workshops that we organized on mobile sensor security. In these workshops, the participants were introduced to mobile sensors by working with sensor-enabled apps. We evaluated the risk levels perceived by the participants for these sensors after they understood the functionalities of these sensors. The results showed that knowing sensors by working with sensor-enabled apps would not immediately improve the users’ security inference of the actual risks of these sensors. However, other factors such as the prior general knowledge about these sensors and their risks had a strong impact on the users’ perception. We also taught the participants about the ways that they could audit their apps and their permissions. Our findings showed that when mobile users were provided with reasonable choices and intuitive teaching, they could easily self-direct themselves to improve their security and privacy. Finally, we provide recommendations for educators, app developers, and mobile users to contribute toward awareness and education on this topic.
Keywords: mobile sensors, IoT sensors, sensor security, security education, app permission, mobile security awareness, user privacy, user security, sensor attacks
Introduction
According to The Economist[1], smartphones have become the fastest-selling gadgets in history, outselling personal computers (PCs) four to one. Today, about half the adult population owns a smartphone; by 2020, 80% will. Mobile and smart device vendors are increasingly augmenting their products with various types of sensors such as the Hall effect sensor, accelerometer, NFC (near-field communication) sensor, heart rate sensor, and iris scanner, which are connected to each other through the internet of things (IoT). We have observed that approximately 10 new sensors have been augmented or became popular in mainstream mobile devices in less than two years, bringing the number of mobile sensors to more than 30 sensors. Examples include FaceID, Active edge, depth cameras (using infrared), thermal cameras, air sensors, laser sensors, haptic sensors, iris scanners, heart rate sensors, and body sensors.
Sensors are added to mobile and other devices to make them smart: to sense the surrounding environment and infer aspects of the context of use, and thus to facilitate more meaningful interactions with the user. Many of these sensors are used in popular mobile apps such as fitness trackers and games. Mobile sensors have also been proposed for security purposes, e.g., authentication[2][3], authorization[4], device pairing[5], and secure contactless payment.[6] However, malicious access to sensor streams results in an installed app running in the background with an exploit path. Researchers have shown that user PINs and passwords can be disclosed through sensors such as the camera and microphone[7], the ambient light sensor[8], and the gyroscope.[9] Sensors such as NFC can also be misused to attack financial payments.[10]
In our previous research[11][12][13][14], we have shown that the sensor management problem is spreading from apps to browsers. We proposed and implemented the first JavaScript-based side channel attack revealing a wide range of sensitive information about users such as phone calls’ timing, physical activities (sitting, walking, running, etc.), touch actions (click, hold, scroll, and zoom) and PINs on mobile phones. In this attack, the JavaScript code embedded in the attack web page listens to the motion and orientation sensor streams without needing any permission from the user. By analyzing these streams via machine learning algorithms, this attack infers the user’s touch actions and PINs with an accuracy of over 70% on the first try. The above research attracted considerable international media coverage, including by the Guardian[15] and the BBC[16], which reassures the importance of the topic. We disclosed the identified vulnerability described in the above to the industry. While working with World Wide Web Consortium (W3C) and browser vendors (Google Chromium, Mozilla Firefox, Apple, etc.) to fix the problem, we came to appreciate the complexity of the sensor management problem in practice and the challenge of balancing security, usability, and functionality.
Through a series of user studies over the years[13][14], we concluded that mobile users are not generally familiar with most sensors. In addition, we observed that there is a significant disparity between the actual and perceived risk levels of sensors. In another work[17], the same conclusion was made by Crager et. al. for motion sensors. We discussed how this observation, along with other factors, renders many academic and industry solutions ineffective at managing mobile sensors.[14] Given that sensors are going beyond mobile devices, e.g., in a variety of IoT devices in smart homes and cities, the sensor security problem has already attracted more attention not only from researchers, but also from hackers. In view of all this, we believe that there is much room for more focus on people’s awareness and education about the privacy and security issues of sensor technology.
Previous research[14][17] has focused on individual user studies to study human aspects of sensor security. In this paper, we present the results of a more advanced teaching method—working with sensor-enabled apps—on the risk level that users associate with the PIN discovery scenario for all sensors. We reflect the results of two interactive workshops that we organized on mobile sensor security. These workshops covered the following: an introduction of mobile sensors and their applications, working with sensor-enabled mobile apps, an introduction of the security and privacy issues of mobile sensors, and an overview of how to manage the app permissions on different mobile platforms.
In these workshops, the participants were sitting in groups and introduced to mobile sensors by working with sensor-enabled apps. Throughout the workshops, we asked the participants to fill in a few forms in order to evaluate the general knowledge they had about mobile sensors, as well as their perceived risk levels for these sensors after they understood their functionalities. After analyzing these self-declared forms, we also measured the correlation between the knowledge and perceived risk level for mobile sensors. The results showed that knowing sensors by working with sensor-enabled apps would not immediately improve the users’ security inference of the actual risks of these sensors. However, other factors such as the prior general knowledge about these sensors and their risks have a strong impact on the users’ perception. We also taught the participants about the ways that they could audit their apps and their permissions, including per app vs. per permission. Our participants found both models useful in different ways. Our findings show that when mobile users are provided with reasonable choices and intuitive teaching, they can easily self-direct themselves to improve their security and privacy.
In the next section, we list the available sensors on mobile devices and categorize them, and then we present the current permission policies for these sensors on Android, iOS, and mobile web browsers. In the subsequent section, we present the structure of these workshops in full detail. Afterwards, we include our analysis on the general knowledge and perceived risk levels that our participants had for sensors and their correlation, followed by our observations of the apps’ and permissions’ review activities in the workshops. We then go on to present a list of our recommendations to different stakeholders. Finally, in the final two sections, we include limitations, future work, and the conclusion.
Mobile sensors
As stated, there are more than 30 sensors on mobile devices. Both iOS and Android, as well as mobile web browsers, allow native apps and JavaScript code in web pages to access most of these sensors. Developers can have access to mobile sensors either by (1) writing native code using mobile OS APIs[18][19], (2) recompiling HTML5 code into a native app[20], or (3) using standard APIs provided by the W3C[21], which are accessible through JavaScript code within a mobile browser.
As shown by Taylor and Martinovic[22], the average number of permissions used by Android apps increases over time, in particular for popular apps and free apps. These permissions are requested for having access to the operating system (OS) resources such as contacts and files, as well as sensors such as the GPS and microphone. This has the potential to make apps over-privileged and unnecessarily increase the attack surface.
Mobile sensors' categorization
We first created a list of available sensors on various mobile devices. We prepared this list by inspecting the official websites of mainstream mobile devices such as the iPhone X, Samsung Galaxy S9, Google Pixel 2, as well as the specifications that W3C[23], Android[18], and Apple[19] provide for developers. We proposed categorizing these sensors into four main groups: identity-related (biometric) sensors, communicational sensors, motion sensors, and ambient (environmental) sensors, as presented in Table 1. Note that this list can be even longer if all mobile brands are included. For example, the Cat S61 smart phone has sensors such as a thermal camera, an air sensor (measures the quality of the environmental air), and a laser sensor (to measure distance).
|
In Appendix A (see the supplemental material at the end), we present a brief description of each sensor. With the growing number of sensors on mobile devices, categorizing them into a few groups is much more difficult than before. Some of these sensors can belong to multiple groups. For example, one might argue that GPS belongs to the environmental category; however, since it is associated with people’s identities, we propose to keep it in the identity-related category. Similarly, the sensor hub monitors the device’s movements, which is associated with the user’s activities. Hence, it is difficult to decide to which category (motion or biometric) it belongs.
Sensor management challenges
In Table 2, we present how the Android, iOS, and W3C specs (followed by mobile browsers) treat different sensors in terms of access. We used the Android and Apple developer websites, the W3C specifications, and caniuse.com to build this table.[18][19][23][24] As can be seen, permission policies for having access to different sensors vary across sensors and platforms. We argue that sensing is still unmanaged on existing smartphone platforms. The in-app access to certain sensors including GPS, camera, and microphone requires user permission when installing and running the app. However, as Simon and Anderson have discussed[7], an attacker can easily trick a user into granting permission through social engineering (e.g., presenting it as a free game app). Once the app is installed and the permission approved, usage of the sensor data is not restricted. On the other hand, access to many other sensors such as accelerometers, gyroscopes, and light sensors is unrestricted; any app can have free access to the sensor data without needing any user permission, as these sensors are left unmanaged on mobile operating systems.
References
NotesThis presentation is faithful to the original, with only a few minor changes to presentation. Grammar was cleaned up for smoother reading. In some cases important information was missing from the references, and that information was added. A few of the inline URLs were turned into citations for this version. The inline URL to Altmetric from the original article was removed for this version because it was a dead URL. The W3C Device and Sensors Working Group URl also changed; an archived version of the site was used for the citation in this version. |