Difference between revisions of "Journal:What is this sensor and does this app need access to it?"
Shawndouglas (talk | contribs) (Saving and adding more.) |
Shawndouglas (talk | contribs) (Saving and adding more.) |
||
| Line 51: | Line 51: | ||
===Mobile sensors' categorization=== | ===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 [https://support.apple.com/kb/SP770?locale=en_US iPhone X], [https://www.samsung.com/uk/smartphones/galaxy-s9/specs/ Samsung Galaxy S9], [https://store.google.com/gb/product/pixel_2_specs Google Pixel 2], as well as the specifications that | 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 [https://support.apple.com/kb/SP770?locale=en_US iPhone X], [https://www.samsung.com/uk/smartphones/galaxy-s9/specs/ Samsung Galaxy S9], [https://store.google.com/gb/product/pixel_2_specs Google Pixel 2], as well as the specifications that W3C<ref name="DAPArch18">{{cite web |url=https://www.w3.org/2009/dap/ |archiveurl=https://web.archive.org/web/20180101221340/https://www.w3.org/2009/dap/ |title=Device and Sensors Working Group |publisher=W3C |archivedate=01 January 2018}}</ref>, Android<ref name="AndroidSensors18" />, and Apple<ref name="AppleCore18" /> 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 [https://www.catphones.com/en-gb/help-support/s60-support/#technical-specs 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). | ||
{| | {| | ||
| Line 84: | Line 84: | ||
|} | |} | ||
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.<ref name="AndroidSensors18" /><ref name="AppleCore18" /><ref name="DAPArch18" /><ref name="AndroidSensorsOver18">{{cite web |url=https://developer.android.com/guide/topics/sensors/sensors_overview.html |title=Sensors Overview |work=Android Developer Guides |publisher=Google |date=2018 |accessdate=30 November 2018}}</ref> 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<ref name="SimonPIN13" />, 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== | ==References== | ||
| Line 89: | Line 93: | ||
==Notes== | ==Notes== | ||
This 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. | This 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. | ||
<!--Place all category tags here--> | <!--Place all category tags here--> | ||
Revision as of 23:05, 25 November 2019
| 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 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
- ↑ "Planet of the Phones". The Economist. The Economist Newspaper Limited. 26 February 2015. https://www.economist.com/leaders/2015/02/26/planet-of-the-phones. Retrieved 30 November 2018.
- ↑ De Luca, A.; Hang, A.; Brudy, F. et al. (2012). "Touch me once and i know it's you!: Implicit authentication based on touch screen patterns". Proceedings of the 2012 SIGCHI Conference on Human Factors in Computing Systems: 987–96. doi:10.1145/2207676.2208544.
- ↑ Bo, C.; Zhang, L.; Li, X.-Y. et al. (2013). "SilentSense: Silent user identification via touch and movement behavioral biometrics". Proceedings of the 19th Annual International Conference on Mobile Computing & Networking: 187–90. doi:10.1145/2500423.2504572.
- ↑ Li, H.; Ma, D.; Saxena, N. et al. (2013). "Tap-Wave-Rub: Lightweight malware prevention for smartphones using intuitive human gestures". Proceedings of the Sixth ACM Conference on Security and Privacy in Wireless and Mobile Networks: 25–30. doi:10.1145/2462096.2462101.
- ↑ Mayrhofer, R.; Gellersen, H. (2007). "Shake Well Before Use: Authentication Based on Accelerometer Data". In LaMarca, A.; Langheinrich, M.; Truong, K.N.. Pervasive Computing - Pervasive 2007. pp. 144–61. doi:10.1007/978-3-540-72037-9_9. ISBN 9783540720379.
- ↑ Mehrnezhad, M.; Hao, F.; Shahandashti, S.F. (2015). "Tap-Tap and Pay (TTP): Preventing the Mafia Attack in NFC Payment". In Chen, L.; Matsuo, S.. Security Standardisation Research - SSR 2015. pp. 21–39. doi:10.1007/978-3-319-27152-1_2. ISBN 9783319271521.
- ↑ 7.0 7.1 Simon, L.; Anderson, R. (2013). "PIN skimmer: Inferring PINs through the camera and microphone". Proceedings of the Third ACM workshop on Security and Privacy in Smartphones & Mobile Devices: 67–78. doi:10.1145/2516760.2516770.
- ↑ Spreitzer, R. (2014). "PIN Skimming: Exploiting the Ambient-Light Sensor in Mobile Devices". Proceedings of the 4th ACM Workshop on Security and Privacy in Smartphones & Mobile Devices: 51–62. doi:10.1145/2666620.2666622.
- ↑ Xu, Z.; Bai, K.; Zhu, S. (2012). "TapLogger: Inferring user inputs on smartphone touchscreens using on-board motion sensors". Proceedings of the Fifth ACM Conference on Security and Privacy in Wireless and Mobile Networks: 113–24. doi:10.1145/2185448.2185465.
- ↑ Mehrnezhad, M.; Ali, M.A.; Hao, F. et al. (2016). "NFC Payment Spy: A Privacy Attack on Contactless Payments". In Chen, L.; Matsuo, S.. Security Standardisation Research - SSR 2016. pp. Article 4. doi:10.1007/978-3-319-49100-4_4. ISBN 9783319491004.
- ↑ Mehrnezhad, M.; Toreini, E.; Shahandashti, S.F. et al. (2016). "TouchSignatures: Identification of user touch actions and PINs based on mobile sensor data via JavaScript". Journal of Information Security and Applications 26: 23–38. doi:10.1016/j.jisa.2015.11.007.
- ↑ Mehrnezhad, M.; Toreini, E.; Shahandashti, S.F. et al. (2015). "TouchSignatures: Identification of user touch actions based on mobile sensors data via JavaScript". Proceedings of the 10th ACM Symposium on Information, Computer and Communications Security: 673. doi:10.1145/2714576.2714650.
- ↑ 13.0 13.1 Mehrnezhad, M.; Toreini, E.; Shahandashti, S.F. et al. (2016). "Stealing PINs via Mobile Sensors: Actual Risk versus User Perception". Proceedings of the 1st European Workshop on Usable Security, EuroUSEC 2016: 1–14. doi:10.14722/eurousec.2016.23008. https://www.ndss-symposium.org/ndss2016/eurousec-2016-workshop/#session1.
- ↑ 14.0 14.1 14.2 14.3 Mehrnezhad, M.; Toreini, E.; Shahandashti, S.F. et al. (2018). "Stealing PINs via mobile sensors: actual risk versus user perception". International Journal of Information Security 17 (3): 291–313. doi:10.1007/s10207-017-0369-x.
- ↑ Hern, A. (11 April 2017). "Tilted device could pinpoint pin number for hackers, study claims". The Guardian. https://www.theguardian.com/technology/2017/apr/11/tilted-device-could-pinpoint-pin-number-for-hackers-study-claims. Retrieved 30 November 2018.
- ↑ "The way people tilt their smartphone 'can give away passwords and pins'". BBC Newsbeat. BBC. 11 April 2017. http://www.bbc.co.uk/newsbeat/article/39565372/the-way-people-tilt-their-smartphone-can-give-away-passwords-and-pins. Retrieved 30 November 2018.
- ↑ 17.0 17.1 Crager, K.; Maiti, A.; Jadliwala, M. et al. (2017). "Information Leakage through Mobile Motion Sensors: User Awareness and Concerns". Proceedings of the 2nd European Workshop on Usable Security, EuroUSEC 2017: 1–15. doi:10.14722/eurousec.2017.23013. https://www.ndss-symposium.org/eurousec-2017-workshop/.
- ↑ 18.0 18.1 18.2 "Sensors". Android Developer Guides. Google. 2018. https://developer.android.com/guide/topics/sensors/index.html. Retrieved 30 November 2018.
- ↑ 19.0 19.1 19.2 "Core Motion". Apple Developer Documentation. Apple. 2018. https://developer.apple.com/documentation/coremotion. Retrieved 30 November 2018.
- ↑ Jin, X.; Hu, X.; Ying, K. et al. (2014). "Code Injection Attacks on HTML5-based Mobile Apps: Characterization, Detection and Mitigation". Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security: 66–77. doi:10.1145/2660267.2660275.
- ↑ "All Standards and Drafts Tagged as Web API". W3C. https://www.w3.org/TR/?tag=webapi.
- ↑ Taylor, V.F.; Martinovic, I. (6 June 2016). "A Longitudinal Study of App Permission Usage Across the Google Play Store". arXiv. https://arxiv.org/abs/1606.01708v1. Retrieved 30 November 2018.
- ↑ 23.0 23.1 "Device and Sensors Working Group". W3C. Archived from the original on 01 January 2018. https://web.archive.org/web/20180101221340/https://www.w3.org/2009/dap/.
- ↑ "Sensors Overview". Android Developer Guides. Google. 2018. https://developer.android.com/guide/topics/sensors/sensors_overview.html. Retrieved 30 November 2018.
Notes
This 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.
