Clarifying recommendations on Android internal storage encryption

[azabost]

Hello everyone,

I've come across what seems to be an inconsistency in the recommendations regarding internal storage encryption for Android. I'd like to get some clarification and share thoughts on this.

These recommendations state that sensitive data should not be stored unencrypted in SharedPreferences or a database:

However, since data stored in a SharedPreferences object is written to a plain-text XML file so its misuse can often lead to exposure of sensitive data. (...) This code violates several best practices.

Sensitive information should not be stored in unencrypted SQLite databases.

However, another paragraph about plain files in internal storage does not mention the need for encryption.

Files saved to internal storage are containerized by default and cannot be accessed by other apps on the device. When the user uninstalls your app, these files are removed. The following code snippets would persistently store sensitive data to internal storage.

This strikes me as inconsistent because both SharedPreferences and databases are also stored in internal storage.

From my understanding, data stored in internal storage—be it a plain file, SharedPreferences, or a database—is only accessible to the owning app itself as long as the device is not rooted. Given this, I'm questioning whether storing unencrypted sensitive data in internal storage truly poses a security risk under normal conditions. Does the omission of encryption requirements for plain files in internal storage imply that encryption isn't strictly necessary in such cases? Or is this an oversight that should be addressed for consistency in the guidelines?

MASTG-TEST-0001 makes the following distinction:

NOTE: For MASVS L1 compliance, it is sufficient to store data unencrypted in the application's internal storage directory (sandbox). For L2 compliance, additional encryption is required using cryptographic keys securely managed in the Android KeyStore.

which seems reasonable to me.

MASWE-0006 mentions a few circumstances when storing unencrypted data on the internal storage could pose a risk:

Mobile apps may need to store sensitive data locally within private storage locations such as the application sandbox and this data is at risk of exposure via, for example, incorrect file permissions, an app vulnerability, device vulnerability or data backup mechanisms.

While a device vulnerability can't be foreseen by the application author, all the other cases seem to be preventable or debatable:

• incorrect file permission - will never happen because Context.MODE_PRIVATE is obligatory since API 17 (according to this)
• app vulnerability - ambiguous
• data backup mechanisms
  • contradicted by "If the device was encrypted, then the backup files will be encrypted as well" (according to this)
  • can also be switched off entirely

That being said, I'm unsure if storing unencrypted sensitive data on internal storage is actually a big problem or not. Or how big of a problem it is.

Since I'm not too experienced with rooting, I'm also unsure if the root detection mechanisms are reliable enough to assume that their presence can justify storing unencrypted data on internal storage.

Looking forward to hearing others' perspectives on this.

Thanks!

[cpholguera]

Hey @azabost, first of all, thank you very much for taking the time to send us this very detailed analysis and apologies for the delay in responding.

Please note that these chapters are not necessarily meant to be recommendations (that's the work of the vulnerability and mitigation teams). They describe how things work on the platform.

However, you are right about the inconsistencies, so thank you! I think these nuances are worth noting, even in the theory chapters.

Storing unencrypted sensitive data on internal storage may or may not be a problem, depending on the threat model of the target application. As the paragraph you copied states:

• For MASVS L1 compliance, it is sufficient to store data unencrypted in the application's internal storage directory (sandbox).
• For L2 compliance, additional encryption is required using cryptographic keys that are securely managed in the Android KeyStore.

This is done according to the profiles we have defined:

Introducing MAS Testing Profiles: A Comprehensive Approach to Mobile App Security Verification

MAS-L1 assumes that:

• The security controls of the mobile operating system can be trusted (e.g. the device is not rooted/jailbroken).
• The primary user of the device is not considered an adversary.
• Other applications installed on the device are considered adversaries. However, MAS-L1 applications only handle low-risk sensitive (user) data and do not contain sensitive functionality.

Root detection is therefore “out of scope” here, it’s a hardening measure that can be applied as an additional protection but knowing that it can be bypassed. If the goal is to retrieve files stored in the internal storage, e.g. a DB containing data that’s proprietary to the developers.

An attacker with root access will be able to obtain that data, even if it’s encrypted. So the encryption is really protecting from trivial retrieval and from the case where the data may be unintentionally exposed to other apps.

So this is the plan:

• Review and fix https://mas.owasp.org/MASTG/0x05d-Testing-Data-Storage/ to clarify WHEN this is a problem
  • “However, since data stored in a SharedPreferences object …“
  • “Sensitive information should not be stored in unencrypted SQLite databases.“
  • “Files saved to internal storage are containerized by default and cannot be accessed by other apps on the device.”
• Review and fix https://mas.owasp.org/MASWE/MASVS-STORAGE/MASWE-0006/
  • Clarify that incorrect file permission - will never happen after minSDKversion 17 because Context.MODE_PRIVATE is obligatory since API 17
  • Specify what we mean by “app vulnerability”, this can be e.g. an incorrectly exposed content provider.
  • Maybe we need to specify the types of data
    • User sensitive data (encrypted to prospect from other apps on the device and from others obtaining the backup)
    • Proprietary / Business assets (IP) (encrypted to protect from other apps on the device)
• Review and fix https://mas.owasp.org/MASTG/0x05d-Testing-Data-Storage/#backups
  • "If the device was encrypted, then the backup files will be encrypted as well"
  • Specify that the backup can be decrypted by the user’s password. So this is protecting user sensitive data from others (not the users themselves).