Android Security by Introspection

Android Security by Introspection

Android Security by Introspection João Vasco Bispo Estrela Supervisors: Prof. Doutor Rolando da Silva Martins Master João Miguel Maia Soares de Resende January 24, 2019 Contents List of Tables 3 List of Figures 4 Acronyms 5 1 Introduction 6 1.1 Motivation . .7 1.2 Proposed Solution . .8 1.2.1 Objectives . .8 1.2.2 Features . .9 2 Background Concepts 10 2.1 Android . 10 2.1.1 Rooting . 12 2.2 Aspect Oriented Programming . 12 3 State of the Art 13 3.1 Android Permissions Model . 13 3.2 Similar Applications . 14 3.2.1 TaintDroid . 14 1 3.2.2 MockDroid . 14 3.2.3 PmP . 15 3.2.4 RefineDroid + Dr. Android + Mr. Hide . 16 3.2.5 RV-Android . 16 3.2.6 WeaveDroid . 16 3.2.7 Adrenaline-RV . 17 3.2.8 SRT-AppGuard . 18 3.2.9 Comparison . 18 3.3 AspectJ . 21 3.4 Flowdroid & SuSi . 21 3.5 dex2jar . 21 3.6 Docker & Kubernetes . 21 3.7 OpenAPI . 22 4 Proposal 24 4.1 Requirements . 24 4.2 Architecture . 24 4.2.1 Sobek Application . 25 4.2.2 Sobek Remote Server . 26 5 Work Plan 28 References 30 2 List of Tables 3.1 Comparison Features Criteria . 19 3.2 Related Work Comparison . 20 5.1 Gantt Diagram . 29 3 List of Figures 1.1 Mobile phones and privacy timeline . .7 2.1 Android Platform Architecture . 11 3.1 TaintDroid architecture within Android [8] . 14 3.2 Architecture of PmP [5] . 15 3.3 RefineDroid + Dr. Android + Mr. Hide architecture [14] . 16 3.4 Weave Droid context [9] . 17 3.5 Architecture of Adrenaline-RV [20] . 17 3.6 Schematics of AppGuard [2] . 18 3.7 Docker + Kubernetes Architecture Example . 22 3.8 OpenAPI Driven Development . 23 4.1 Sobek Application Architecture . 25 4.2 Sobek Remote Server Architecture . 27 4.3 Sobek Server Instrumentation Tool . 27 4 Acronyms PSTN Public Switched Telephone Network SMS Short Message Service OS Operating System AOP Aspect-Oriented Programming GDPR General Data Protection Regulation API Application Programming Interface HAL Hardware Abstraction Layer REST Representational State Transfer JSON JavaScript Object Notation YAML YAML Ain’t Markup Language UI User Interface HTTPS Hyper Text Transfer Protocol Secure APK Android Package 5 Chapter 1 Introduction The innovations in the field of microprocessors have lead to the creation of devices with large computing power that are able to be carried by anyone, anywhere. One example of these devices is the mobile phones that started with a constrained number of functions in the early stages only voice such as in the Public Switched Telephone Network (PSTN) network, and later with messages with the purpose of easing com- munications. In early 2000 the smartphone reintroduced a new paradigm (figure 1.1). This new iteration of mobile devices brought hardware that enabled many the usage of today features like internet connectivity, cameras and all kind of sensors. By 2007 new mobile operating systems (Android, IOS, Windows Phone) started to emerge to make the use of this modern hardware and quickly replaced the old ones. These innovations made easy to perform many tasks that previously required a personal computer but came at the cost of collecting user information to execute them. Was at this time that one of the most controversial problems of today started to rise. The lack of privacy. These modern devices capable of performing many tasks that before were thought impossible on such small and mobile equipment became enormous deposits of personal data that hold high value in today’s markets. This data is extremely valuable to sell as with this data there can be made advertisement profiles for targeting ads. It can, in addition, be used to discriminate the users based on information that would be practically impossible to know, like sexual orientation or religious beliefs by reading Short Message Service (SMS) or recording the microphone. The Android operating system has provided multiple layers to protect user privacy over time. In the early versions only applications from the official store, the Google Play Store, were available and the applications had to go through reviews before being available and display what kind of functionalities of the device are accessed, 6 Figure 1.1: Mobile phones and privacy timeline but with the swift growth this approach began to be a downside for the users, that required applications for their needs and for the developers that would need to go by the review process that was considered a waste time. Later this path was simplified with the review process being much more friendly and tolerant believing that the users would have a conscious attitude taking the in formations displayed on each application into account before installing. Quickly malicious agents realized the users didn’t care about the warnings and flooded the application store with software to grab personal information to make a quick buck. By Android 6.0 (Marshmallow), in 2015, it had evolved since its release and many updates brought security features like Permission Manager[10] to make the users more conscious about what is being accessed by the applications. But this feature doesn’t solve the complete problem since it lacks a method to display for what those permissions are used for. Currently, Android has grown to be the most popular Mobile Operating System with 88% of the market share [19] and is one of the most attractive platforms for personal data collection. A large number of permissions present in today’s Android Operating System (OS) is hindering the user’s capability of comprehending what is happening and shared by the various applications in their smartphones. We propose the usage of introspection within the Android apps, via code injection using Aspect-Oriented Programming (AOP), to transparently collect metering data that can be used to notify the user or/and sink into a secure back-end. 1.1 Motivation Today many applications still request permissions that do not need and may not even work if those are unprovided just as a way to collect data to sell to a third-party. With 7 these problems in mind, an effort to regulate this kind of practices was made in 2016 by the states in the European Union and the European Economic Area by the form of the General Data Protection Regulation (GDPR) [17]. The article 1 of chapter 1 of GDPR [17] lays down rules relating to the protection of natural persons with regard to the processing of personal data and rules relating to the free movement of personal data. 1.2 Proposed Solution In this section, we describe the objectives and features of the proposed solution to our problem. With the problem in mind, our solution is named after Sobek, an Egyptian deity considered to be a fierce protector that wards off the evil and defend the innocent. 1.2.1 Objectives • Technology research: By reviewing the state of art we aim to identify the progress done to combat our problem and learn the pros and cons of each approach to propose a more efficient solution. • Architecture design: The definition of architecture is fundamental it helps to comprehend how the requirements of the solution relate to the implementation and the data flow between components should act. • Implementation: The effort to implement the proposed solution should be able to combine the most recommended practices found in the research together with the planned architecture. This implementation should deliver a tool which offers improvements to our problem. • Security and privacy test: In the end, we should look at the proposed solution and its implementation to analyze the security and privacy improvements made. • Deployment in a real environment: Taking in consideration the most used application of the Play Store, conduct a study regarding the support, perfor- mance overhead and information leakage of the application. 8 1.2.2 Features • Easy migration: The users should be able to use their settings independently on what device they are using. • High privacy level: With this solution we aim to provide an improvement for the users on how their information is accessed and used. • High availability: The solution should be able to be used anywhere, anytime, online or offline. While online, the servers should always be accessible. • Interoperability: The connectivity between devices and applications remain unaffected as any changes do not alter the process of communication however only the sensitive information is modified. • Remote control: The solution should be able to offer remote control capabili- ties as it can be a highly pursued feature for certain use-cases. • Profiling: The creation and usage of user-defined profiles with fake sensitive data is crucial to deliver an intrusive free experience on some applications. 9 Chapter 2 Background Concepts 2.1 Android Android is an open source, Linux-based software stack created for a wide array of devices and form factors [11]. This stack can be also referred to as a mobile operating system as its structure and functionalities resemble a traditional OS. Figure 2.1 rep- resents the several layers of abstraction present in the OS and what they encapsulate. The System Apps layer is where the core applications reside and are distributed with the OS and provide methods to utilize the most basic features of a smartphone like calls, texting, keyboard or web-browser. These apps ain’t any different from an application developed by a third-party other than being the default behaviour of the device. The Java Application Programming Interface (API) Framework provides the develop- ers with a set of tools to ease the development of applications by enabling the use of components, services and core functionalities specially developed to interact with the OS.

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    33 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us