What are the benefits to using Jetpack's EncryptedSharedPreferences and EncryptedFile?

Question

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.

Answer 1

Based 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_pref folder 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 sharedPref files, you can do it from Android Studio

1. Open Android Studio
2. Run your application on an Emulator
3. on Device File Explorer(Bottom Right of the Android Studio)
4. Find your package name within the data/data directory.

Answer 2

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 EncryptedSharedPreferences the 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

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

The application developer can assure some security level for the application data via standard API.

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

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.