使用JetPack的EncryptedSharedPreference和EncryptedFile有什么好处？
阅读了大量文章和堆叠式帖子后，我找不到使用的理由 与使用其未加密的反零件相比，GentedSharedPreferences或EncryptedFile。
首先，我想谈论必须考虑安全性的两个状态：
- 设备 不妥协
- 设备
当设备<强>不妥协，该应用程序是沙盒。只要应用程序遵循 android的安全性最佳实践，那么该应用程序应该很好 - 安全明智。由于内部应用程序数据在不包含设备时是安全的，因此无需对其进行加密。
当设备受到损害时，应用程序几乎无法保护自身。唯一的真正策略是最大程度地减少设备上敏感数据的量。但是，EncryptedSharedPreferences和EncryptedFile似乎意味着即使设备 受到妥协，它也可以保护用户数据，就像在Android的博客中所讨论的那样/2020/02/data-encryption-on-android-with-jetpack.html“ rel =“ noreferrer”>使用Jetpack Security上的Android上的数据加密：
您为什么要在应用中加密数据？默认情况下，Android（自5.0以来，都不会对用户数据分区的内容进行加密？确实可以，但是在某些用例中，您可能想要额外的保护 ...在应用程序主目录中，如果您的应用程序处理敏感信息，包括但不限于有限，您的应用程序应加密数据以个人身份的信息（PII），健康记录，财务详细信息或企业数据。
但是“额外的保护水平”是什么意思？根据同一博客：
在我们加密数据之前，重要的是要了解如何确保您的加密密钥安全。 JetPack Security使用主密钥...生成并存储在AndroidKeystore中。
因此，JetPack的EncryptedSharedPreferences和EncyptedFile使用 keystore 生成和存储钥匙以供键进行ocyys生成和存储。通过检查源代码。这也是问题所在。
密钥库不是旨在生成键来加密设备本地数据。作为帖子 Android-使用硬件支持的密钥库与仅软件钥匙店与没有密钥库的实际安全好处是什么？指出：
关键存储的目的不是限制对应用程序或应用程序数据的访问，而是为了保护凭证在使用过程中暴露。由于钥匙店将愿意利用其知识来加密数据或访问敏感的应用程序信息，因此攻击者在所有三种类型中的许多故障中指出，攻击者的利用并不是一个挑战。
。
这意味着，在设备上，恶意程序可以使用密钥库来解密所有先前加密的数据。 android文档确认这一点：
如果Android OS被妥协或攻击者可以读取设备的内部存储，则攻击者可能能够在Android设备上使用任何应用程序的Android键盘键，但不能从设备中提取它们。
这完全将加密SharedPreferences和EncryptedFile进行的任何加密完全取消，当设备受到损害时。
回顾：当设备不妥协时，内部应用数据是安全的。当设备遭到损害时，无论是否通过加密SharedPreferences/EncryptedFile对其进行加密，内部应用数据都不安全。
问题：
如果以上是正确的，那么使用gentedsharedPreference和evenptedFile有什么好处？与其非注册的对应物相比，是否有特定方案可以保护内部应用程序数据，可以保护内部应用程序数据？
编辑1：
正如评论中指出的那样，“内部应用数据”是模棱两可的。具体来说，我的意思是/data/data/data/＆lt; package name＆gt;的位置，该位置受应用程序砂盒和凭据加密保护。另外，就这个问题而言，我想专注于Android 10+，就像需要FBE时一样。但是，我也对较低的Android版本中的方案感兴趣（在撰写本文时，加密SharedPreferences/EncryptedFile的最低API级别为21）。
编辑2：
在重新阅读了问题之后，我认为在这里清楚的是的内容也很重要。密钥库由2个主要部分组成：一个物理组件（例如TEE，SOC，HSM）和一个OS守护程序。物理组件是代表操作系统执行加密操作的事情，因此没有过程（包括OS）可以知道密钥是什么。 OS守护程序是限制物理组件使用的方法。由于OS守护程序限制了使用情况，因此恶意程序（在设备上）可以规避这些限制并直接使用物理组件。这就是为什么不应该使用密钥库来对设备 local 进行加密数据的原因。物理组件仅提供攻击者不知道密钥本身的属性，而不是他们不能使用它。可以找到有关密钥库的更多信息在这里//source.android.com/security/keystore“ rel =“ noreferrer”>在这里。
After reading over tons of articles and stackoverflow posts, I can't find a concrete reason to use
EncryptedSharedPreferences or EncryptedFile compared to using their non-encrypted counter-parts.
To start off with, I want to talk about the 2 states of a device that security must be thought about:
- the device is not compromised
- the device is compromised
When the device is not compromised, the application is sandboxed. As long as the application follows Android's Security Best Practices, then the application should be fine -- security wise. Because internal app data is safe when the device is not comprised, there is no need to encrypt it.
When the device is compromised, there is very little an application can do to protect itself. The only real strategy is to minimize the amount of sensitive data on the device. However, EncryptedSharedPreferences and EncryptedFile seems to imply that it can protect user data even when the device is compromised, as talked about in Android's Blog 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.
But what does it mean by "extra level of protection"? According to the same Blog:
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.
So Jetpack's EncryptedSharedPreferences and EncyptedFile uses the KeyStore to generate and store the keys for encryption. This is verified by examining the source code. And this is also where the problem is.
The KeyStore is not intended to generate keys to encrypt data local to the device. As the answer to the post Android - What are the practical security benefits of using a hardware-backed keystore vs software-only keystore vs no keystore points out:
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.
This means that, on a compromised device, a malicious program can use the KeyStore to decrypt all of the previously encrypted data. The Android Documentation acknowledges this:
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.
This completely nullifies any encryption done by EncryptedSharedPreferences and EncryptedFile when the device is compromised.
To recap: When the device is not compromised, internal app data is safe. When the device is compromised, internal app data is not safe, regardless of whether it is encrypted via EncryptedSharedPreferences/EncryptedFile or not.
Question:
If the above is true, then what are the benefits to using EncryptedSharedPreferences and EncryptedFile? Is there a specific scenario where EncryptedSharedPreferences and EncryptedFile can protect internal app data, as compared to their non-encrypted counterparts?
EDIT 1:
As pointed out in the comments, "internal app data" is ambiguous. Specifically, I mean the location at /data/data/<package name>, which is protected by app sand-boxing and credential encryption. Also, in terms of this question, I would like to focus on Android 10+ as this is when FBE was required. However, I am also interested in scenarios in lower Android versions too (at the time of writing, minimum API level for EncryptedSharedPreferences/EncryptedFile is 21).
EDIT 2:
After re-reading the question, I think its also really important to be clear here by what the KeyStore is. The KeyStore consists of 2 major parts: a physical component (e.g. TEE, SoC, HSM) and an OS daemon. The physical component is the thing that performs crypto operations on behalf of the OS, so no process (including the OS) can know what the key is. The OS daemon is the thing that restricts usage of the physical component. Because the OS daemon restricts usage, a malicious program (on a compromised device) can circumvent those restrictions and directly use the physical component. This is the reason why the KeyStore is not supposed to be used to encrypt data that remains local to the device. The physical component only provides the property that the key itself will not be known by an attacker, not that it can't be used by them. More information about the KeyStore can be found here and here.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果设备受到损害，则可以疑问整个系统的安全性，并且所有数据都可能被视为暴露。如果设备不妥协，则操作系统本身应保证应用程序，数据和执行环境的安全性。
我详细介绍了另一个州，该设备正在由第三方分析，在许多情况下，在离线模式下 - 可能是执法主题或小偷。
根据DOCS
EncryptedSharedPreferences首选项文件获得加密，因此在REST 上保护数据。这种安全级别与设备的其他安全方面无关（可选的FDE或SD卡加密），并且可以由应用程序开发人员管理。使用Android密钥库应允许通过标准和稳定的API使用Android安全功能（例如HSM）。回答
应用程序开发人员可以通过标准API确保应用程序数据的某些安全级别。
是的，在对设备（或存储）上的邪恶女仆或离线攻击期间，EncryptedSharedPreferences/EncryptedFile可以为应用程序数据提供保护，或者至少提高将此类数据获取所需的标准到非平地级别。
If device is compromised, the security of whole system is in doubt and all data might being considered exposed. If device is not compromised, the OS itself should guarantee safety of the applications, data and execution environment.
I'd elaborate on another state, the device being analyzed by a 3rd party, in many cases in offline mode -- possibly law enforcement subject or a thief.
According to docs
EncryptedSharedPreferencesthe preferences file gets encrypted hence protect data at rest. This level of security is independent of other security aspects of the device (optional FDE or SD card encryption) and is manageable by the application developer. Using Android KeyStore should allow to use of the Android security features (such as HSM) via standard and stable API.Answer
The application developer can assure some security level for the application data via standard API.
Yes, during evil-maid or offline attack on the device (or storage), EncryptedSharedPreferences/EncryptedFile can provide protection for the application data or at least raise the bar required to acquire such data to non-trivial level.
基于我的知识和经验。
gentedsharedPreferences 即使在扎根设备中也可以保护用户数据。
当您在实现中创建共享Preferences对象时，将在称为
shared_pref的目录中创建文件，它将包括您在代码实现中传递的文件名。此
shared_pref文件夹位于数据/数据/您的软件包名称中。如果设备扎根，则可以访问此目录，因此可以利用内部的数据。
它很容易读取首选项文件，因为它是映射文件，键和如下值：
，如果您使用 encryptedsedsharedprefences ，您的键和值由默认值，因此即使设备是根，也无法利用数据。
如下：
如果您需要检查
sharedPref文件，则可以从Android StudioBased on my knowledge and expereince in this part.
EncryptedSharedPreferences came to secure user data even in rooted devices.
When you create a SharedPreferences object in your implementation, a file is created in a directory called
shared_pref, and it would include the filename you passed in your code implementation.This
shared_preffolder is located in data/data/your package name.This directory is accessible if the device is rooted, so data inside could be exploited.
It's easy to read the preferences file as it's a map file, with key and values like the following:
while, if you used EncryptedSharedPrefences, your key and value are encrypted by default, so even the device is root no data could be exploited.
like the following:
If you need to check your
sharedPreffiles, you can do it from Android Studio