android - 使用 Jetpack 的 EncryptedSharedPreferences 和 EncryptedFile 有什么好处？

Question

在阅读了大量文章和 stackoverflow 帖子后，我找不到使用的具体理由
EncryptedSharedPreferences 或 EncryptedFile 与使用它们的非加密对应部分相比。
首先，我想谈谈必须考虑安全性的设备的两种状态:

设备不是 妥协

设备是 妥协

当设备 不是 受到损害，应用程序被沙盒化。只要申请遵循 Android's Security Best Practices ，那么应用程序应该没问题——安全方面。因为在不包含设备时内部应用数据是安全的，因此无需对其进行加密。
当设备 是 受到损害，应用程序几乎无法保护自己。唯一真正的策略是尽量减少设备上的敏感数据量。但是，EncryptedSharedPreferences 和 EncryptedFile 似乎暗示它可以保护用户数据，即使设备 是 妥协，正如 Android 博客 Data Encryption on Android with Jetpack Security 中所述:

Why would you want to encrypt data in your app? Doesn’t Android, since 5.0, encrypt the contents of the user's data partition by default? It certainly does, but there are some use cases where you may want an extra level of protection... In the app home directory, your app should encrypt data if your app handles sensitive information including but not limited to personally identifiable information (PII), health records, financial details, or enterprise data.

但是“额外的保护级别”是什么意思呢？根据同一个博客:

Before we jump into encrypting your data, it’s important to understand how your encryption keys will be kept safe. Jetpack Security uses a master key... which is generated and stored in the AndroidKeyStore.

所以 Jetpack 的 EncryptedSharedPreferences 和 EncyptedFile 使用 KeyStore生成和存储用于加密的 key 。这通过检查 source code 得到验证。 .这也是问题所在。
keystore 不是 旨在生成 key 以加密设备本地的数据。作为帖子 Android - What are the practical security benefits of using a hardware-backed keystore vs software-only keystore vs no keystore的答案指出:

The purpose of a key store is not to restrict access to an application or application data, it's purpose is to protect the credential from being exposed during use. Since a key store will willingly leverage its knowledge to encrypt data or access sensitive application information, it's not really a challenge for an attacker to leverage as you pointed out in many of your breakdowns across all three types.

这意味着，在受感染的设备上，恶意程序可以使用 KeyStore 来解密所有先前加密的数据。 Android Documentation承认这一点:

If the Android OS is compromised or an attacker can read the device's internal storage, the attacker may be able to use any app's Android Keystore keys on the Android device, but not extract them from the device.

当设备受到威胁时，这完全取消了 EncryptedSharedPreferences 和 EncryptedFile 所做的任何加密。
回顾一下:当设备没有受到威胁时，内部应用数据是安全的。当设备被入侵时，内部应用数据是不安全的，无论它是否通过 EncryptedSharedPreferences/EncryptedFile 加密。
问题:
如果上述情况属实，那么使用 EncryptedSharedPreferences 和 EncryptedFile 有什么好处？与未加密的对应项相比，是否存在 EncryptedSharedPreferences 和 EncryptedFile 可以保护内部应用程序数据的特定场景？
编辑1:
正如评论中所指出的，“内部应用数据”是模棱两可的。具体来说，我指的是 /data/data/<package name> 的位置。 ，受应用沙盒和凭证加密保护。另外，就这个问题而言，我想关注 Android 10+，因为这是需要 FBE 的时候。但是，我也对较低 Android 版本的场景感兴趣(在撰写本文时，EncryptedSharedPreferences/EncryptedFile 的最低 API 级别为 21)。
编辑2:
重新阅读问题后，我认为在这里弄清楚 KeyStore 是什么也非常重要。 KeyStore 由 2 个主要部分组成:一个物理组件(例如 TEE、SoC、HSM)和一个操作系统守护程序。物理组件是代表操作系统执行加密操作的东西，因此没有进程(包括操作系统)可以知道 key 是什么。操作系统守护进程是限制物理组件使用的东西。由于操作系统守护程序限制使用，恶意程序(在受感染的设备上)可以绕过这些限制并直接使用物理组件。这就是为什么不应该使用 KeyStore 来加密设备本地的数据的原因。物理组件只提供 key 本身不会被攻击者知道的属性，而不是不能被他们使用的属性。有关 KeyStore 的更多信息，请访问 here和 here .

Answer 1

如果设备受到威胁，整个系统的安全性就会受到质疑，所有数据都可能被视为暴露。如果设备没有受到威胁，操作系统本身应该保证应用程序、数据和执行环境的安全。
我将详细说明另一种状态，该设备由第三方分析，在许多情况下处于离线模式 - 可能是执法主体或小偷。
根据文档 EncryptedSharedPreferences首选项文件被加密，因此可以保护静态数据。这种安全级别独立于设备的其他安全方面(可选的 FDE 或 SD 卡加密)，并且可由应用程序开发人员管理。使用 Android KeyStore 应该允许通过标准和稳定的 API 使用 Android 安全功能(例如 HSM)。
回答

... what are the benefits to using EncryptedSharedPreferences and EncryptedFile?

应用程序开发人员可以通过标准 API 确保应用程序数据的某些安全级别。

Is there a specific scenario where EncryptedSharedPreferences and EncryptedFile can protect internal app data, as compared to their non-encrypted counterparts?

是的，在对设备(或存储)进行恶意或离线攻击期间，EncryptedSharedPreferences/EncryptedFile 可以为应用程序数据提供保护，或者至少将获取此类数据所需的阈值提高到非平凡的水平。