Jetpack EncryptedSharedPreferences与EncryptedFile的使用优势

我查阅了大量技术文章与Stack Overflow帖子，始终没找到相较于普通非加密版本，使用EncryptedSharedPreferences或EncryptedFile的确切理由。

安全分析的前提：两类设备状态 #

讨论安全问题首先要明确设备的两种安全状态：

• 设备未被入侵
• 设备已被入侵

当设备未被入侵时，应用运行在沙箱隔离环境中，只要遵循Android官方安全最佳实践，应用安全就能得到保障。未被入侵的设备上，应用内部数据本身就是安全的，不需要额外加密。
当设备已被入侵时，应用自身的防护能力非常有限，唯一可行的安全策略是尽可能减少设备本地存储的敏感数据量。

官方宣传与机制本身的矛盾 #

Jetpack安全库的官方宣传似乎表明，EncryptedSharedPreferences与EncryptedFile即便在设备被入侵时也能保护用户数据。Android官方博客《Data Encryption on Android with Jetpack Security》中提到：

为什么需要在应用内加密数据？Android从5.0版本开始不是默认加密用户数据分区吗？确实如此，但部分场景下你可能需要额外一层保护……如果应用处理个人可识别信息（PII）、健康记录、财务信息、企业数据等敏感内容，应当对应用主目录下的数据进行加密。

但这里提到的“额外一层保护”具体指什么？同一篇博客给出的说明是：

在开展数据加密工作前，需要先了解加密密钥的安全存储机制：Jetpack Security使用生成并存储在AndroidKeyStore中的主密钥完成加密操作。

查阅官方源码可以证实，Jetpack的EncryptedSharedPreferences与EncryptedFile确实使用KeyStore生成并存储加密密钥，但这恰恰是争议点所在。KeyStore的设计初衷并不是生成本地数据加密密钥，正如安全社区相关讨论指出：

密钥库的设计目的不是限制对应用或应用数据的访问，而是防止凭据在使用过程中被泄露。由于密钥库会主动响应加密、访问敏感应用信息的请求，攻击者可以轻易利用密钥库完成恶意操作。

这意味着在已被入侵的设备上，恶意程序可以调用KeyStore解密所有之前通过该密钥加密的数据，Android官方文档也明确承认这一点：

如果Android操作系统被攻破，或攻击者具备设备内部存储读取权限，攻击者或许能够在设备上使用任意应用的Android Keystore密钥，但无法将密钥提取出设备。

这就直接导致设备被入侵时，EncryptedSharedPreferences与EncryptedFile提供的加密保护完全失效。

初步推论 #

总结下来可以得到两个结论：

• 设备未被入侵时，应用内部数据本身受沙箱保护，本身就是安全的
• 设备被入侵时，无论是否使用EncryptedSharedPreferences/EncryptedFile加密，应用内部数据都不再安全

核心问题 #

如果上述推论成立，那么使用EncryptedSharedPreferences与EncryptedFile的实际收益是什么？相较于非加密的对应组件，是否存在特定场景下这两个加密组件可以切实保护应用内部数据？

补充说明 #

范围界定 #

正如评论区指出，“应用内部数据”的表述存在歧义，此处特指存储路径为/data/data/<package name>的目录，该位置受应用沙箱与凭据加密双重保护。本问题主要聚焦强制要求文件级加密（FBE）的Android 10及以上版本，同时也覆盖更低Android版本的适用场景（截至当前，EncryptedSharedPreferences/EncryptedFile支持的最低API等级为21）。

KeyStore的工作逻辑说明 #

首先明确KeyStore的构成，它包含两大核心部分：

• 物理硬件组件：如可信执行环境TEE、片上系统SoC、硬件安全模块HSM，代表操作系统执行加密运算，任何进程（包括操作系统本身）都无法获取密钥明文
• 操作系统守护进程：负责限制物理组件的访问权限

在被入侵的设备上，恶意程序可以绕过守护进程的权限限制，直接调用物理组件完成运算，这也是KeyStore不适用于本地留存数据加密的核心原因：物理组件仅能保证密钥本身不被攻击者窃取，无法阻止攻击者使用密钥完成解密操作。更多KeyStore相关信息可参考Android官方开发者文档与AOSP安全说明文档。

内容的提问来源于stack exchange，提问作者user19309143