8 security encryption android android-keystore android-jetpack
在阅读了大量文章和 stackoverflow 帖子后，与使用非加密对应部分相比，我找不到使用 EncryptedSharedPreferences 或 EncryptedFile 的具体原因。
\n首先，我想谈谈必须考虑安全性的设备的两种状态：
\n当设备未受到损害时，应用程序将被沙箱化。只要应用程序遵循Android 的安全最佳实践，那么应用程序就应该没问题——安全方面。由于当设备不包含在内时，内部应用程序数据是安全的，因此无需对其进行加密。
\n当设备受到损害时，应用程序几乎无法保护自己。唯一真正的策略是最大限度地减少设备上的敏感数据量。然而，EncryptedSharedPreferences 和 EncryptedFile 似乎意味着即使设备受到威胁，它也可以保护用户数据，正如 Android 博客Data Encryption on Android with Jetpack Security中所述：
\n\n\n为什么要加密应用程序中的数据？Android从5.0开始默认加密用户数据分区的内容吗？当然可以，但在某些用例中，您可能需要额外级别的保护...在应用程序主目录中，如果您的应用程序处理敏感信息（包括但不限于个人身份信息 (PII)），则您的应用程序应该加密数据、健康记录、财务详细信息或企业数据。
\n
但“额外保护级别”是什么意思呢？根据同一个博客：
\n\n\n在我们开始加密您的数据之前，了解如何保证您的加密密钥的安全非常重要。Jetpack Security 使用主密钥...生成并存储在 AndroidKeyStore 中。
\n
因此Jetpack的EncryptedSharedPreferences和EncyptedFile使用KeyStore来生成和存储用于加密的密钥。这是通过检查源代码来验证的。而这也是问题所在。
\nKeyStore无意生成密钥来加密设备本地数据。正如Android - What are the effective security Benefits of using a hardware-backed keystore vs software-only keystore vs no keystore 的回答所 指出的：
\n\n\n密钥存储的目的不是限制对应用程序或应用程序数据的访问，而是保护凭证在使用过程中不被泄露。由于密钥存储愿意利用其知识来加密数据或访问敏感应用程序信息，因此正如您在所有三种类型的许多故障中所指出的那样，这对于攻击者来说并不是真正的挑战。
\n
这意味着，在受感染的设备上，恶意程序可以使用 KeyStore 解密所有先前加密的数据。Android文档承认了这一点：
\n\n\n如果 Android 操作系统遭到破坏或攻击者可以读取设备的内部存储，则攻击者可能能够使用 Android 设备上任何应用程序的 Android 密钥库密钥，但无法从设备中提取它们。
\n
当设备受到威胁时，这将完全无效由 EncryptedSharedPreferences 和 EncryptedFile 完成的任何加密。
\n回顾一下：当设备未受到损害时，内部应用程序数据是安全的。当设备受到威胁时，内部应用程序数据并不安全，无论是否通过 EncryptedSharedPreferences/EncryptedFile 进行加密。
\n问题：
\n如果上述情况属实，那么使用 EncryptedSharedPreferences 和 EncryptedFile 有什么好处？与未加密的对应项相比，是否存在 EncryptedSharedPreferences 和 EncryptedFile 可以保护内部应用程序数据的特定场景？
编辑1：
\n正如评论中指出的，“内部应用程序数据”不明确。具体来说，我指的是 的位置/data/data/<package name>，该位置受应用程序沙箱和凭证加密的保护。另外，就这个问题而言，我想重点关注 Android 10+，因为这是需要 FBE 的时候。不过，我也对较低 Android 版本中的场景感兴趣（在撰写本文时，EncryptedSharedPreferences/EncryptedFile 的最低 API 级别为 21）。
编辑2：
\n重新阅读问题后，我认为弄清楚 KeyStore是什么也非常重要。KeyStore 由 2 个主要部分组成：物理组件（例如 TEE、SoC、HSM）和操作系统守护进程。物理组件是代表操作系统执行加密操作的组件，因此任何进程（包括操作系统）都无法知道密钥是什么。操作系统守护程序是限制物理组件使用的东西。由于操作系统守护程序限制使用，恶意程序（在受感染的设备上）可以绕过这些限制并直接使用物理组件。这就是为什么不应使用 KeyStore 来加密设备本地数据的原因。物理组件仅提供密钥本身不会被攻击者知道的属性，而不是攻击者不能使用它。有关 KeyStore 的更多信息可以在此处和此处找到。
如果设备受到损害，整个系统的安全性就会受到质疑，所有数据都可能被视为暴露。如果设备不受到损害，操作系统本身应该保证应用程序、数据和执行环境的安全。
我将详细说明另一种状态，即设备正在由第三方进行分析，在许多情况下处于离线模式 - 可能是执法主体或小偷。
根据文档，EncryptedSharedPreferences首选项文件被加密，因此可以保护静态数据。此安全级别独立于设备的其他安全方面（可选的 FDE 或 SD 卡加密），并且可由应用程序开发人员管理。使用 Android KeyStore 应允许通过标准且稳定的 API 使用 Android 安全功能（例如 HSM）。
...使用 EncryptedSharedPreferences 和 EncryptedFile 有什么好处？
应用程序开发人员可以通过标准 API 保证应用程序数据的一定安全级别。
与未加密的对应项相比，是否存在 EncryptedSharedPreferences 和 EncryptedFile 可以保护内部应用程序数据的特定场景？
是的，在对设备（或存储）进行邪恶女仆或离线攻击期间，EncryptedSharedPreferences/EncryptedFile 可以为应用程序数据提供保护，或者至少将获取此类数据所需的门槛提高到不平凡的水平。
| 归档时间： |
|
| 查看次数： |
1942 次 |
| 最近记录： |