android 驱动层_Android的各层

android 驱动层

系列概述： (Series outline:)

• Part 1: A Short History of Mobile Malware

  第1部分： 移动恶意软件的简要历史

• Part 2: The Layers of the Android Security Model (you are here)

  第2部分： Android安全模型的各层( 您在此处)

• Part 3: Mitigating Android Social Engineering Attacks

  第3部分 ： 缓解Android社交工程攻击

In the first part, we have identified that the user is the primary vulnerability exploited by attackers.

在第一部分中 ，我们已经确定用户是攻击者利用的主要漏洞。

But why is that?

但是为什么呢？

Why do attackers bother coming up with a convincing story when they could simply exploit the vulnerabilities of the Android OS?

当攻击者仅能利用Android OS的漏洞时，为什么还要费心地提出一个令人信服的故事 ？

In this part, we will explore the Android security model in order to understand WHY is the user the weaker link of the model.

在这一部分中，我们将探索Android安全模型 ，以了解WHY是用户该模型的较薄弱环节。

三方同意模型 (Three Party Consent Model)

In order to abstract unnecessary details, we will frame the Android security model as a three party consent model.

为了抽象出不必要的细节，我们将Android安全模型构造为三方同意模型。

The security model is based on the consent of the following parties:

安全模型基于以下各方的同意：

1. Operating System

   操作系统

2. Application

   应用

3. End-User

   最终用户

The Three Parties of the Consent Model

同意模型的三方

For an action to be successfully executed, all three parties must agree on it.

为了成功执行一项动作，所有三个方面都必须对此达成一致。

Since Android is primarily focused on the end user, the system has to be secure by default.

由于Android主要针对最终用户，因此默认情况下该系统必须安全。

The user expects the other two parties to have taken the necessary measures to ensure his safety.However, when the nature of the action requires his consent, the end-user is the decisive factor when it comes to the security of the overall system.

用户希望其他两方都采取必要的措施来确保自己的安全。但是，当操作的性质需要他的同意时， 最终用户是整个系统安全的决定性因素 。

For the rest of the article, we will explore the security measures enforced by the three parties in order to prevent malicious actions from being successfully executed.

在本文的其余部分，我们将探索由三方强制执行的安全措施 ，以防止恶意操作被成功执行。

1.操作系统安全 (1. Operating System Security)

The kernel is the core operating system software that handles the CPU resources, the system memory, the system devices, including the file systems and networking, and is responsible for managing all the processes. It serves as a link between the software and the hardware.

内核是核心操作系统软件，用于处理CPU资源，系统内存，系统设备(包括文件系统和网络)，并负责管理所有进程。 它充当软件和硬件之间的链接。

However, with great power comes great responsibility. The kernel security determines the overall security of the whole system.

但是， 强大的力量带来巨大的责任。 内核安全性决定了整个系统的整体安全性。

Android’s kernel is based on the Linux kernel’s long-term support (LTS) branches. The decades of continuous improvement have established Linux as a stable and reliable kernel amongst many businesses and security professionals.

Android的内核基于Linux内核的长期支持(LTS)分支。 经过数十年的不断改进，Linux已成为许多企业和安全专业人员中稳定 ， 可靠的内核。

The security of the Android operating system is based around the following key security features of the Linux kernel:

Android操作系统的安全性基于Linux内核的以下关键安全性功能：

• Process Isolation

  Craft.io隔离

• User-Based Permission Model

  基于用户的权限模型

• Inter-Process Communication (IPC)

  进程间通信(IPC)

沙盒¹ (Sandboxing¹)

Android platform uses the Linux user-based permissions model to isolate application resources.

Android平台使用Linux 基于用户的权限模型来隔离应用程序资源。

This process in called application sandbox.

此过程称为应用程序沙箱 。

Sandboxing Mechanism

沙箱机制

The aim of sandboxing is to prevent malicious external programs from interacting with the protected app.

沙箱的目的是防止恶意外部程序与受保护的应用程序进行交互 。

The internal operating system components are also protected by the sandboxing mechanism. The vulnerabilities exposed by an application cannot be exploited to gain access to the outer system.

内部操作系统组件也受沙箱保护。 应用程序暴露的漏洞无法利用来访问外部系统。

The secure communication between applications is ensured by the Linux user-based protection. Unlike traditional operating systems, e.g. MacOS and Windows, Android uses the User ID (UID) concept to manage an application’s access control and not the system user’s access control. An application is prohibited from accessing other application’s data or system features without the necessary permissions.

基于 Linux 用户的保护可确保应用程序之间的安全通信。 与传统操作系统(例如MacOS和Windows)不同，Android使用用户ID(UID)概念来管理应用程序的访问控制，而不是系统用户的访问控制。 没有必要的权限，禁止应用程序访问其他应用程序的数据或系统功能。

The application is sandboxed at the kernel level, hence it is guaranteed that the application is isolated from the rest of the system, regardless of specific development environment, programming languages or APIs used.

该应用程序是在内核级别进行沙箱处理的，因此可以确保该应用程序与系统的其余部分隔离，而无论使用哪种特定的开发环境，编程语言或API。

By default, applications have limited access to the operating system. This ensures that a malicious application cannot get access to the external system from the inside.

默认情况下，应用程序只能访问操作系统。 这样可以确保恶意应用程序无法从内部访问外部系统。

生根² (Rooting²)

To overcome the limitations of the sandbox model, the user is able to root the device. On a Linux system, root is the name of the account that has access to all files and commands. Being based on Linux, Android has this concept as well.

为了克服沙箱模型的局限性，用户可以使设备成为root用户。 在Linux系统上， root是有权访问所有文件和命令的帐户的名称。 基于Linux，Android也具有此概念。

Although counterintuitive, the owner of the device is NOT root. This design decision was made for security reasons. If the owner was able to do anything in the system, it would be easier for malicious applications to get control over the entire system by tricking the user into granting them the same permissions.

尽管违反直觉，但设备的所有者不是 root。 出于安全原因做出此设计决定。 如果所有者能够在系统中执行任何操作，则恶意应用程序将通过诱骗用户授予相同的权限，从而更容易控制整个系统。

But as we’ve already seen, Android is designed to be open. Consequently, the user is allowed to root the phone, i.e. switch to the root user.

但是正如我们已经看到的，Android被设计为开放的 。 因此，允许用户使电话成为root用户，即切换到root用户。

It should be noted that rooting is not recommended to be done by inexperienced users. Rooting a phone might result in making the warranty null and void. One should always weight the advantages and disadvantages of rooting before proceeding.

应该注意的是，不建议没有经验的用户进行生根。 拔掉手机可能会导致保修无效。 在进行之前，应始终权衡生根的优缺点。

After rooting, we can no longer rely on the security measures enforced by the operating system. This means that we are effectively taking the whole system into our own hands, have control over everything, and dispose the beautifully engineered security systems in favour of a customised experience.

扎根后，我们将不再依赖操作系统实施的安全措施。 这意味着我们可以有效地将整个系统掌握在自己手中，可以控制一切，并可以根据定制的体验来配置精美的安全系统。

经过验证的靴子³ (Verified Boot³)

Verified Boot is a process that ensures that the device is booting the original operating system alongside the afferent system code, and not a malicious replica.

验证启动是一种过程，可确保设备与传入的系统代码一起(而非恶意副本)在引导原始操作系统 。

Similarly to the Blockchain technology, the Verified Boot establishes a chain of trust between the multiple components that can be altered, starting from the hardware up to the verified partitions. If any of the components up the chain is altered, the whole chain is invalidated and the user is warned.

与区块链技术类似，“验证的启动”在可以更改的多个组件之间建立信任链 ，从硬件到验证的分区。 如果更改了链中的任何组件，则整个链将失效，并警告用户。

The device state can be one of the following:

设备状态可以是以下之一：

• LOCKED: no custom software can be flashed on the device and boot verification is active

  锁定 ：无法在设备上刷新自定义软件，并且启动验证处于活动状态

• UNLOCKED: custom software can be flashed on the device and boot verification is inactive

  已解锁 ：可以在设备上刷新自定义软件，并且启动验证无效

Root of trust is a cryptographic key used to sign the Android copy that runs on the device. This key is part of the boot verification. We are able to replace this key in order to run custom Android versions. By doing so, we can keep the verified boot mechanism even if we use a different OS version.

信任根是用于对设备上运行的Android副本进行签名的加密密钥。 该密钥是引导验证的一部分。 我们可以替换此密钥，以运行自定义的Android版本。 这样，即使我们使用其他操作系统版本，也可以保留经过验证的启动机制。

Android is continuously delivering minor security updates alongside the major ones that come with every new Android version. The minor updates usually patch discovered vulnerabilities.

Android会不断提供次要安全更新以及每个新Android版本随附的主要更新。 次要更新通常修补发现的漏洞。

An attacker might try to downgrade the Android version running on the device in order to exploit vulnerabilities that were patched. This class of attacks is mitigated by Rollback Protection. Rollback Protection is part of the Verified Boot process.

攻击者可能试图降级设备上运行的Android版本，以利用已修补的漏洞 。 通过回滚保护可以缓解此类攻击。 回滚保护是“验证启动”过程的一部分。

2.应用安全 (2. Application Security)

The security aspect of an application is often overlooked. The lack of concern can determine the application to transform into an attack vector, leveraged by malicious actors.

应用程序的安全性方面经常被忽略 。 无需担心，可以确定将应用程序转换为恶意参与者利用的攻击媒介 。

权限⁴ (Permissions⁴)

In Android, the user’s privacy is protected by the means of permissions. Android applications requires the user’s consent to perform actions that might impact other applications, the operating system or the user himself.

在Android中，用户的隐私通过权限保护。 Android应用程序需要用户同意才能执行可能影响其他应用程序，操作系统或用户本人的操作。

The permissions required by an application are declared in the AndroidManifest.xml. Every permission is specified in its own uses-permission tag.

应用程序所需的权限在AndroidManifest.xml中声明。 每个许可都在其自己的使用许可标签中指定。

Runtime permission

运行时权限

Some permissions are granted to the application by default when specified. However, the other category of permissions, called dangerous permissions, require special consent from the user.

指定后，默认情况下会将某些权限授予应用程序。 但是，另一类权限称为危险权限 ，需要用户的特殊同意。

Depending on the Android version running on the device, dangerous permissions are required as:

根据设备上运行的Android版本，需要危险权限，如下所示：

• Install-time permissions (for Android 5.1.1 and below): When an application is installed, the user is presented with the list of all permissions that the app requires.

  安装时权限 ( 适用于Android 5.1.1及更低版本 )：安装应用程序后，系统会向用户显示该应用程序所需的所有权限的列表。

• Runtime permissions (for Android 6.0 and higher): When an application requests a permission, the user is prompted with a dialog. Unlike install-time permissions, runtime permissions are usually requested when the respective functionality is needed. For example, a camera permission should be requested before the user tries to take a capture.

  运行时权限 ( 适用于Android 6.0及更高版本 )：当应用程序请求权限时，会提示用户对话框。 与安装时权限不同，通常需要相应功能时才请求运行时权限。 例如，在用户尝试进行拍摄之前，应先请求相机许可。

数据存储⁵ (Data Storage⁵)

Markus Spiske via Markus Spiske通过 Unsplash Unsplash

Data storage is, allegedly, the most sensitive field of Android security. Data is the ultimate goal of an attacker. We have to make sure that every option of data storage is properly secured according to the sensitivity of the data saved.

据称，数据存储是Android安全性最敏感的领域 。 数据是攻击者的最终目标。 我们必须确保根据所保存数据的敏感性适当保护每个数据存储选项。

Android provides three ways of saving data on the device :

Android提供了三种在设备上保存数据的方式：

• Internal storage: Data stored here is visible only to the corresponding application. Other applications do not have access to the files stored in the respective application’s directory. When the application is uninstalled, all the data stored here is erased as well.

  内部存储 ：此处存储的数据仅对相应的应用程序可见。 其他应用程序无权访问存储在相应应用程序目录中的文件。 卸载应用程序后，此处存储的所有数据也会被删除。

• External storage: Data stored in external storage is globally readable and writable. This means that any application can read or write the files stored here. Therefore, it is necessary for the application’s sensitive information to be stored in the internal storage. However, in case the information can be safely saved publicly, we should make the necessary validations when we try to read it back. Since the data can be altered by other applications or attackers, we can’t be certain that the data we previously wrote didn’t transform into a dynamically-loaded malware.

  外部存储 ：存储在外部存储中的数据是全局可读和可写的。 这意味着任何应用程序都可以读取或写入此处存储的文件。 因此，有必要将应用程序的敏感信息存储在内部存储器中。 但是，以防万一这些信息可以安全地公开保存，我们在尝试读回该信息时应进行必要的验证。 由于数据可能会被其他应用程序或攻击者更改，因此我们无法确定先前编写的数据不会转变为动态加载的恶意软件 。

• Content providers: They provide an abstraction over the data stored. With the use of content providers, we have more control over the read and write permissions. If we develop multiple applications under the same signature, we can share data between them with the use of a content provider, so that the data is visible only between our applications.

  内容提供者 ：他们提供对所存储数据的抽象。 通过使用内容提供程序，我们可以更好地控制读写权限。 如果我们以相同的签名开发多个应用程序，则可以使用内容提供者在它们之间共享数据，以便仅在我们的应用程序之间可见数据。

It should be noted that the introduction of Scoped Storage, in Android 10, eliminated most of the risks associated to the external storage. We encourage you to take a look at the following article:

应该注意的是， Android 10中范围存储的引入消除了与外部存储相关的大多数风险。 我们鼓励您阅读以下文章：

Moreover, if we wish to persistently store key-value pairs, we can use the SharedPreferences⁶ API provided by Android.

此外，如果我们希望持久存储键值对，则可以使用Android提供的SharedPreferences⁶API 。

A common developer habit is that of storing user’s credentials in the SharedPreferences. However, we should design our data storage by thinking that everything stored can end up in the hands of an attacker. All the permissions and protections can be nulled if the device is rooted.

开发人员的常见习惯是将用户凭据存储在SharedPreferences中。 但是，我们应该通过考虑存储的所有内容都可以落入攻击者的手中来设计数据存储。 如果设备是root用户，则所有权限和保护都可以为空 。

To add an extra layer of security we can encrypt the data stored. To encrypt the data, Android provides the Security⁷ library that includes, inter alia, two classes for data encryption:

为了增加额外的安全性，我们可以对存储的数据进行加密 。 为了加密数据，Android提供了Security⁷库，该库尤其包括两个用于数据加密的类：

• EncryptedFile: Provides a custom implementation over FileInputStream and FileOutputStream, effectively creating more secure data streams — data is encrypted and decrypted on every I/O operation

  EncryptedFile ：在FileInputStream和FileOutputStream上提供自定义实现，有效地创建更安全的数据流-在每个I / O操作中对数据进行加密和解密

• EncryptedSharedPreferences: Provides a secure layer over SharedPreferences. Automatically encrypts keys and values using a two-scheme method.

  EncryptedSharedPreferences ：在SharedPreferences上提供安全层。 使用两种方案自动加密密钥和值。

进程间通信(IPC) (Interprocess Communication (IPC))

The Android IPC mechanisms allow us to enforce security policies based on the relation between our application and the other end.

Android IPC机制使我们能够根据应用程序与另一端之间的关系来实施安全策略。

Android provides the following classes that facilitate the interprocess communication:

Android提供了以下有助于进程间通信的类：

• Intent

  意图

• Binder

  活页夹

• Messenger

  信使

The aforementioned mechanisms usually work in conjugation with services and broadcast receivers.

前述机制通常与服务和广播接收器结合使用。

Intents are the go-to mechanism of passing data when working with activities or broadcast listeners. Intents can be either explicit or implicit.

意图是在与活动或广播侦听器一起工作时传递数据的首选机制。 意图可以是显 式的也可以是隐式的 。

Explicit intents are designed to be received by an explicit component, hence the name. This way, we can be sure that the data sent from application A is received only by the application B. Moreover, explicit intents can be used to send data between activities inside our applications.

显式意图被设计为由显式组件 (即名称)接收。 这样，我们可以确保从应用程序A发送的数据仅由应用程序B接收。此外，可以使用显式意图在应用程序内部的活动之间发送数据。

In contrast, implicit intents specify an action that should be performed. Depending on the action, the intent might include some data needed for the respective action. Implicit intents are usually used when our application cannot do an action and we want to delegate the task to a third-party application.

相反， 隐式意图指定应执行的操作。 根据操作，意图可能包括相应操作所需的一些数据。 当我们的应用程序无法执行操作并且我们希望将任务委托给第三方应用程序时，通常会使用隐式意图。

For example, to send a message from an application to another application, an intent with the ACTION_SEND action should be used.Any application that declares an intent-filter on the ACTION_SEND action can intercept the implicit intent. When multiple applications can respond to an implicit intent, a chooser is shown. If only an application can respond to this, the respective application is selected implicitly and no chooser is shown.

例如，从一个应用程序将消息发送到另一个应用程序，一个意图与ACTION_SEND动作要used.Any申请声明对意向滤波器 ACTION_SEND动作可以拦截隐式意图。 当多个应用程序可以响应隐式意图时，将显示一个选择器。 如果只有一个应用程序可以对此做出响应，则隐式选择相应的应用程序，并且不显示选择器。

A security risk is raised when we use an implicit intent to bind to a service. Using an implicit intent makes it possible for a malicious service to respond to the request, effectively intercepting all the communication. Fortunately, starting with Android 5.0, an exception is thrown if the intent passed to the bindService method is an implicit intent.

当我们使用隐式意图绑定到服务时，会带来安全风险。 使用隐式意图可以使恶意服务响应该请求，从而有效拦截所有通信。 幸运的是，从Android 5.0开始，如果传递给bindService方法的意图是隐式意图， bindService引发异常。

Binder and Messenger are used to implement remote procedure call (RPC) IPC in Android. They provide an interface that facilitates secure communication between an application and a service.

活页夹和Messenger用于在Android中实现远程过程调用(RPC) IPC。 它们提供了促进应用程序和服务之间安全通信的接口。

应用程序签名 (Application Signing)

Scott Graham via 斯科特·格雷厄姆(Scott Graham)通过 Unsplash Unsplash

Code signing provides developers with the ability to identify the author of an application and seamlessly update it, without the need of cumbersome processes. Applications that are not signed by a developer cannot be uploaded to Google Play.

代码签名使开发人员能够识别应用程序的作者并无缝更新它，而无需繁琐的过程。 未经开发人员签名的应用程序无法上传到Google Play。

Even if an unsigned application package ended up on the device, the application cannot be installed because the package manager checks whether the package is signed or not before installing any application.

即使未签名的应用程序包最终出现在设备上，也无法安装该应用程序，因为程序包管理器会在安装任何应用程序之前检查该程序包是否已签名。

Application signing is the first step in the application sandbox mechanism.An UID is assigned based on the certificate used to sign the application.

应用程序签名是应用程序沙箱机制的第一步。 根据用于签署应用程序的证书分配UID 。

If multiple applications are signed using the same certificate, they can specify the android:sharedUserId key in their manifest so that they share the same UID. However, the key was deprecated in API 29 because it could cause non-deterministic behaviour when assigning the UID, hence it is strongly discouraged to be used and may be removed in future versions.

如果多个应用程序使用同一证书签名，则可以在清单中指定android:sharedUserId密钥，以便它们共享相同的UID。 但是，该密钥在API 29中已被弃用，因为在分配UID时，它可能导致不确定的行为，因此，强烈建议不要使用它，并可能在以后的版本中将其删除。

Applications have the ability to create security permissions protected by the signature. Thus, applications signed under the same certificate, under different UIDs and application sandboxes, can access restricted functionalities exposed by one or the other.

应用程序可以创建受签名保护的安全权限。 因此，在不同的UID和应用程序沙箱下使用同一证书签名的应用程序可以访问彼此公开的受限功能。

Neither the operating system nor the application suit the needs of an attacker due to the plethora of security measures enforced.

由于实施了过多的安全措施，因此操作系统和应用程序都不适合攻击者的需求。

But what about the end-user? What security measures does he enforce?

但是最终用户呢？ 他执行哪些安全措施？

In the next part, we will explore the ways in which the user can protect himself against social engineering attacks.

在下一部分中，我们将探索用户保护自己免受社会工程攻击的方法。

[1] Android Source. Application Sandbox. https://source.android.com/security/app-sandbox

[1] Android Source。 应用程序沙箱。 https://source.android.com/security/app-sandbox

[2] Android Central. Root Your Android Phone: What is Root & How To. https://www.androidcentral.com/root

[2] Android Central。 根您的Android手机：什么是根以及如何。 https://www.androidcentral.com/root

[3] Android Developer. Permissions Overview. https://developer.android.com/guide/topics/permissions/overview

[3] Android开发人员。 权限概述。 https://developer.android.com/guide/topics/permissions/overview

[4] Android Source. Boot flow. https://source.android.com/security/verifiedboot/boot-flow

[4] Android Source。 引导流程。 https://source.android.com/security/verifiedboot/boot-flow

[5] Android Developer. Data and file storage overview. https://developer.android.com/training/data-storage

[5] Android开发人员。 数据和文件存储概述。 https://developer.android.com/training/data-storage

[6] Android Developer. Save key-value data. https://developer.android.com/training/data-storage/shared-preferences

[6] Android开发人员。 保存键值数据。 https://developer.android.com/training/data-storage/shared-preferences

[7] Android Developer. Security library. https://developer.android.com/jetpack/androidx/releases/security

[7] Android开发人员。 安全库。 https://developer.android.com/jetpack/androidx/releases/security

翻译自: https://proandroiddev.com/the-layers-of-the-android-security-model-90f471015ae6

android 驱动层