Ðóññêèé Ðóñ Óêðà¿íñüêà Óêð
DonNTU   Masters' portal

Content

Introduction

Smartphones are now ubiquitous. Technical user literacy is gradually increasing, and with her understanding of the need to ensure the confidentiality and security of personal data. This is especially acute The topic is relevant when developing applications that use personal data of users, banking information, state secret.

Thus, there is a need to improve the efficiency of means and methods for protecting user data in mobile applications.

1. Theme urgency

Given the growing popularity of mobile banking applications, there are serious concerns about their security, because security breaches can lead to financial losses of hundreds of dozens of users [1].

Examination of existing mobile applications by the Digital Security team revealed a number of vulnerabilities and vectors attacks on client banking applications.

In addition, each mobile OS has its own specifics, in each of them you can find a large number of new and well-known vulnerabilities [1].

Thus, the topic of the effectiveness of mobile application security is relevant and requires both learning features Target OS, as well as improvements to existing tools to protect user data.

2. Goal and tasks of the research

The purpose of the study is to increase the effectiveness of methods and means of protecting user data in mobile applications for the Android operating system.

The object of study is the methods and means of protecting user data.


The main objectives of the study:

  1. Examine the architecture of the target operating system (Android) and the built-in protection.
  2. Explore and analyze vulnerabilities and attack vectors.
  3. Improving the effectiveness of existing means and methods of protection.
  4. Evaluate the effectiveness of custom data security tools.
  5. Development of alternative versions of the main stages of the unified process of the synthesis of Moore’s automata and evaluation their effectiveness.

As part of the master's work planned:

  1. Examining existing protection tools and methods in the Android operating system.
  2. Research existing vulnerabilities in mobile apps on Android OS.
  3. Develop your own security module.
  4. Develop a prototype using your own module.
  5. Evaluation of the effectiveness of the protective equipment used in the development of the prototype.

3. Review of research and development

The theme of developing applications for mobile operating systems is quite popular and in demand. But, research of user data security tools requires an examination of the operating system architecture Android.e systems built-in protection.

3.1 Overview of international sources


There are several common mobile application protection tools:

  1. Description of the built-in protection on the official Google website [2].
  2. Recommendations for using built-in protection [3]
  3. A library that implements easy access to encryption in the Android OS [4]

In the Android Security Internals book (Âíóòðåííèå óñòðîéñòâà áåçîïàñíîñòè Android) [5] in detail described internal security structure of the Android OS, considering the implementation of the main components and subsystems associated with security, such as binder ipc, permissions, cryptographic providers, and device administration.

3.2 Overview of national sources


Russian-speaking sources related to security are presented in a small volume and for the most part are translation of English sources.

The Android for Developers (Android äëÿ ðàçðàáîò÷èêîâ) [6] presents advanced development technologies. mobile applications for professional programmers. Each chapter describes the application being developed. An overview is then provided. technologies used in its development process.

3.3 Local Source Overview

No diploma theses describing security in Android OS were found in Donetsk National Technical University.

4. Android operating system architecture

Android is a free and open source project. Most of the source code is distributed under a free license. Apache 2.0. The project began to develop in 2003, and in 2005 the developer was purchased by Google. The first stable version appeared in 2008 [7].

The opinion is “Android is Linux” (Android is Linux). This is due to the fact that Android is based on the core Linux, however, is significantly different from most other Linux systems.

Like other Linux systems, the Linux kernel provides such low-level things as memory management, security data, support multiprocessing and multithreading. But - with a few exceptions - you will not find in Android other familiar components of GNU / Linux systems: there is nothing from the GNU project, not using X.Org, nor even systemd. All these components are replaced by analogues, more adapted for use in conditions of limited memory, low processor speed and minimal power consumption - so Android looks more like embedded Linux system than GNU / Linux.

Also, the Linux kernel itself in Android is also slightly modified: several small ones were added. components, including ashmem (anonymous shared memory), binder driver (part of the binder framework), wakelocks (sleep control) and low memory killer.

Android is not using the GNU C library (glibc) as the libc (standard C library), but its own minimalistic implementation called bionic optimized for embedded systems - it much faster, less and less memory demanding than glibc, which is overgrown with multiple layers compatibility.

Android operating system structure is presented in Figure 1.1.


Figure 1.1 – Android operating system structure


4.1 Android applications


Many operating systems are divided into the actual operating system and applications installed on top, they know nothing about each other and cannot interact. The system of components and intent Android allows applications, still without knowing anything about each other, to create for the user one integrated system user experience - installed applications implement parts of one large system, they make up of themselves the system. And this, on the one hand, is transparent to the user, on the other, it represents unlimited customization capabilities [8].

One of the unique features of Android is that applications do not directly control the process in which they running.

The basic unit in Unix-like systems is the process. And low-level system services, and individual teams in shell and graphical applications are processes. In most cases, the process is a black box for the rest of the system - other components of the system do not know and do not care about its condition. Process starts run from the main () function call (actually _start), and then implements some of its own logic, interacting with the rest of the system through system calls and simple interprocess communication (IPC).

Since Android is also Unix-like, all this is true for it, but while the low-level parts are on Unix level - they use the concept of a process, at a higher level - the Android Framework level - the basic unit is an application. The application is not a black box: it consists of individual components that are well known. the rest of the system.

Android applications have no main () function, no single entry point. In general, Android abstracts the concept as much as possible. The application is running both from the user and from the developer. Of course, the application process needs to be started and stop, but Android does it automatically. The developer is encouraged to implement several separate components, each with its own life cycle.

To implement the interconnection between components, applications need to be able to communicate with each other. friend and system services — in other words, you need a very advanced and fast IPC mechanism. For this Binder is used.

Binder is a platform for fast, convenient, and object-oriented interprocess communication. Binder uses its own small kernel module, which interacts with from userspace through system calls (in mostly ioctl) on a “virtual device” / dev / binder.

Low-level parts of a binder operate in terms of objects that can be sent between processes. Wherein reference counting is used to automatically release unused shared resources and notification of the completion of the remote process (link-to-death) to release resources within the process.

Binder high-level parts work in terms of interfaces, services, and proxies. Interface Description the program provides other programs, written in a special language AIDL (Android Interface Definition Language), looks very similar to interface declaration in Java. According to this description automatically A real Java interface is generated, which can then be used by both clients and the service itself. Besides In addition, two special classes are automatically generated for the .aidl file: Proxy (for use by client) and Stub (from the service side) implementing this interface.

In order for different processes to “find” each other’s services, Android has a special service. ServiceManager, which stores, registers and issues tokens of all other services.

Binder is widely used in Android to implement system services (e.g., package manager and buffer exchange), but the details of this are hidden from the application developer by the high-level classes in the Android Framework, such like Activity, Intent and Context. Applications can also use binder to provide each other own services - for example, the Google Play Services application does not have its own graphical interface for the user, but provides developers of other applications with the opportunity to use the services Google Play.

The main view of Android application components is activity. An activity is one “screen” of an application. For example, in an email client application, there might be an activity such as Inbox Activity (a list of incoming emails), Email Activity (reading one letter), Compose Activity (writing a letter) and Settings Activity (settings).

Data transfer between parts of the application is carried out at the expense of intents. Intent is the message that tells the system what to “do” (for example, open this URL, write a letter to this address, call to this phone number or take a photo).

Applications may need to perform actions that are not directly related to any activity, including continue to do them in the background when all the activity of this application is complete. For example, an application might download from the network a large file, process photos, play music, sync data or just maintain a TCP connection with the server to receive notifications.

Such functionality cannot be implemented simply by running a separate stream — it would be black for the system. a box; including, the process would be completed at the completion of all the activity, regardless of the state of such background operations. Instead, Android suggests using another type of component — a service.

The service is needed to inform the system that during the application process, actions are taken that are not part of activity of this application. The service itself does not mean the creation of a separate thread or process - its points entry points are launched in the main application thread. Usually the service implementation runs additional flows and manages them yourself.

In addition to activity and services, Android applications have two other types of component - these are broadcast receivers and content providers.

Broadcast receiver is a component that allows an application to receive broadcast’s, a special kind of message from system or other applications. Originally, broadcasts, as the name implies, were mainly used for sending broadcast messages to all subscribed applications - for example, the system sends a message AIRPLANE_MODE_CHANGED when you turn on or turn off airplane mode.

Content provider is a component that allows an application to give other applications access to data that it rules. An example of data that can be accessed in this way is the user's contact list.

At the same time, the application can store the data itself in any way, including on the device as files, in this database (SQLite) or request them from the server over the network. In this sense, the content provider is unified interface for accessing data, regardless of the form of their storage. Interaction scheme using Content Provider is presented in Figure 1.2.


Figure 1.2 – Interaction scheme using Content Provider (animation: 4 frames, 500 ms delay, 10 cycles of reparing, 133 KB)


4.2 Android OS Security Components


The Android operating system has a number of built-in features that help reduce frequency and impact. security errors. The system is designed so that when using standard tools to avoid complex security-related solutions [3].

The following basic defenses can be distinguished:

  • an isolated application runtime environment (Android Application Sandbox) that provides code execution and working with data separately from other applications;
  • application framework with reliable implementation of the basic protection functionality such as cryptography, rights access, secure interprocess communication (IPC);
  • technologies like ASLR, NX, ProPolice, safe_iop, OpenBSD dlmalloc, OpenBSD calloc and Linux mmap_min_addr, come from the Linux operating system;
  • file system encryption;
  • permissions granted by the user (User-granted permissions), restricting access to system permissions phone features;
  • permissions specified in the application for managing data based on each application.

Using the listed protections and their combination when writing an application can significantly reduce probability of hacking the application.

Conclusion

The Android operating system has a number of special tools to ensure data security. users. However, there are a number of problems with the implementation of the application that fall on the shoulders of the developer. applications. The developer must know and understand the mechanisms of protection and correctly apply them.

Thus, to improve the effectiveness of methods and means of protecting custom mobile applications It is necessary to develop recommendations for the use of existing funds, as well as implement their own remedies.

References

  1. Áåçîïàñíîñòü ìîáèëüíûõ áàíêîâñêèõ ïðèëîæåíèé [Ýëåêòðîííûé ðåñóðñ] // Inforation Security. – Ðåæèì äîñòóïà: http://itsec.ru/articles... – Çàãë. ñ ýêðàíà.
  2. Security [Ýëåêòðîííûé ðåñóðñ] // Android Source. – Ðåæèì äîñòóïà: https://source.android.com/security – Çàãë. ñ ýêðàíà.
  3. Security tips [Ýëåêòðîííûé ðåñóðñ] // Android Developers. – Ðåæèì äîñòóïà: https://developer.android.com/training... – Çàãë. ñ ýêðàíà.
  4. AeroGear Android Security [Ýëåêòðîííûé ðåñóðñ] // Github. – Ðåæèì äîñòóïà: https://github.com/aerogear... – Çàãë. ñ ýêðàíà.
  5. Elenkov, N. Android Security Internals / N. Elenkov, 2014, - 432 ñ.
  6. Äåéòåë, Ï. Android äëÿ ðàçðàáîò÷èêîâ / Ï. Äåéòåë, Õ. Äåéòåë, À. Óîëä, 2016, - 512 ñ.
  7. Êàê ðàáîòàåò Android, ÷àñòü 1 [Ýëåêòðîííûé ðåñóðñ] // Habrahabr. – Ðåæèì äîñòóïà: https://habrahabr.ru/company... – Çàãë. ñ ýêðàíà.
  8. Êàê ðàáîòàåò Android, ÷àñòü 3 [Ýëåêòðîííûé ðåñóðñ] // Habrahabr. – Ðåæèì äîñòóïà: https://habrahabr.ru/company... – Çàãë. ñ ýêðàíà.