Security Mechanisms in Google Android
In his post, most important security mechanisms deployed in android platform is described.
Android has grown dramatically in the number of active users worldwide since its first release in 2008, and it has become the most used smartphone OS globally by up to 2.5 billion active users around the globe. In a world stepping towards the IoT era, android devices may be considered the most populated IoT devices. Therefore, the dominance and importance of the android operating system should be accepted as a fact, and the security issues in Android should be studied more carefully.
Smartphones are used in various applications such as communication, business (banking applications), social networks, multimedia, fun and entertainment, gaming, healthcare. User data is the most critical asset involved in all these applications, and it is essential to protect users' data in smartphone platforms such as Android.
In this post, we try to describe the security mechanisms in the android platform.
We first look under the hood of android OS and describe its architecture. Then we describe some of the security mechanisms employed in the android OS.
Android Architecture
Android is an open-source software stack of interfaces with multiple layers that provide the optimal application execution and development environment. The interfaces depicted in the below Fig include a Linux Kernel, a set of libraries, a runtime environment, an API framework, and applications [2].
Above the hardware components layer, there is a Linux kernel customized for smart devices with power, memory, and computational constraints. On top of the Linux kernel, a hardware abstraction layer provides standard interfaces that expose device hardware capabilities to the higher-level Java API framework. On top of that, there is a runtime layer that converts the application's DEX bytecode into native code at install time and executes it on Dalvik virtual machine. Android contains several Core Runtime Libraries which offer Java programming language functionality, such as database access, interface construction and graphics rendering [3]. Furthermore, on top of these layers, an application layer allows utility applications to run on Android OS [2].
Android security mechanisms
Android platform has been designed with multiple security mechanisms. It has a hierarchical structure, and each layer has its security mechanism, including Linux security, a traditional access control mechanism, a mechanism based on inspection of permission, a sandbox mechanism, and an encryption mechanism.
Linux security
Android's Linux kernel incorporates the access control mechanism of traditional Linux OS. Users' access to resources and services is restricted based on user authentication and authorization. Android has a Mandatory Access Control (MAC) over traditional Discretionary Access Control (DAC). MAC manages access control decisions on all access attempts as part of the Linux Security Module (LSM) framework. Android's access control policy dramatically limits the potential damage to compromised machines and accounts. It ensures that apps are running at the minimum privilege level, which protects resource confidentiality and integrity [4].
Digital signature mechanism
The digital signature is a prerequisite for an app hosted on Google Play Store. It is generated by a private key certificate allocated by a certifying authority. Therefore, the integrity of the app and the authentication of its developer are insured. If an attacker modifies an APK, it needs to be re-signed for validation, which is only possible if the private key of the original publisher is known to the attacker [2].
Sandboxing
Android runs each app in an isolated kernel-level sandbox environment with its memory and resources. This approach protects developer apps and system apps from malicious ones. However, as the sandbox is at the kernel, all the above software (such as OS libraries, applications, or framework) runs within the sandbox. Therefore, Apps are restricted from interactions. For example, suppose an app X tries to read application Y's resources. In that case, it is prevented because it lacks user privileges unless it has a corresponding resource access id, and this requires permission grants at installation time [4].
Permission model
Android employs a permission-based security model to restrict applications' access using APIs to system resources. Requested permissions to access resources are specified using <uses-permission> tags in the manifest file. Android permission model defines four access levels for permissions [2].
Normal permissions: are required by an app to access data or resources outside its sandbox to isolate application-level features. E.g., ACCESS_NETWORK_STATE
Dangerous permissions: higher risk permission requests exposure to user's private data or device control. For example, access calendar and phone book.
Signature permissions: are used by the developer to share resources among its sibling apps, and it is used to access resources between apps signed by the same developer certificate. E.g., INJECT_EVENTS.
SignatureOrSystem: permissions are required to change system settings and installation privileges. E.g., WRITE_SETTINGS allows an application to alter system settings.
Encryption
User data in Android devices is encrypted using symmetric keys to provide confidentiality and authorized access. All disk write operations on user data follow after encryption, and corresponding read operations precede decryption [2].
Android employs two encryption methods to ensure confidentiality, including File-Based Encryption or FBE and Full Disk Encryption (FDE). Files in FBE are encrypted using different keys, which can be accessed independently [4].
Using the Direct Boot feature FBE enabled devices can boot straight to the lock screen without user credentials. In FDE, user data partition /data is encrypted on block-level using a single key generated by user credential. The encrypted device is detected and prompted for the password during boot time, then decrypt the user partition. FDE used 128 Advanced Encryption Standard (AES) with cipher-block chaining (CBC) for encryption [2].
Inter Component Communication (ICC)
Inter Component Communication is a crucial feature of Android, which is similar to Inter-Process Communication (IPC). It allows an application component to access data from another component within the same application, another application within the same device or an external service. Applications can depend upon others for third-party services by borrowing services. For instance, a package delivery application can depend upon Google Maps for users' geolocation, thus aiding developers. This interaction is done using an asynchronous messaging system called intents [1].
Intents can be divided into two types [2]:
Explicit intents are designed for the fixed target component, and only the component name in intent is considered to identify the target component.
Implicit intents are not for a fixed target and are often used to actuate components in other applications.
When an implicit intent is used, the Android system finds the appropriate component to start by comparing the intent contents to the intent filters declared in the manifest file of other apps on the device.
The intent filtering mechanism cannot be relied on for security. While implicit intents are tested against intent filters for targeting components, the explicit intents can name the components as the target. An explicit intent should be used to start a service. Developers should avoid declaring an intent filter for service components because using an implicit intent to start a service is a security hazard [2].
Conclusion
In conclusion, the extensive use of Android on mobile devices has no foreseeable slowdown. Consequently, developers continue to discover security flaws and formulate novel techniques for protecting Android systems from attackers. Such research evaluation will help software developers formulate their strategies for future malware detection and prevention. In this post, we briefly discussed some security mechanisms deployed in android systems to protect them against malicious attacks.
References
[1]P. Bhat and K. Dutta, "A Survey on Various Threats and Current State of Security in Android Platform," ACM Computing Surveys, vol. 52, no. 1, pp. 1-35, 2019.
[2]V. Sihag, M. Vardhan and P. Singh, "A survey of android application and malware hardening", Computer Science Review, vol. 39, p. 100365, 2021.
[3]S. Garg and N. Baliyan, "Android security assessment: A review, taxonomy and research gap study", Computers & Security, vol. 100, p. 102087, 2021.
[4]R. Mayrhofer, J. Stoep, C. Brubaker and N. Kralevich, "The Android Platform Security Model", ACM Transactions on Privacy and Security, vol. 24, no. 3, pp. 1-35, 2021.
[5] xda-developers, 2020. “The Android Device Security Database helps you compare the security of Android smartphones” [Online]. Available from: https://www.xda-developers.com/android-device-security-database-compare-smartphone/ [Accessed 8 Dec 2021].
