This blog will help you understand the internals Encrypted Shared Preferences. Hence, you need to have a basic knowledge about it. Please go through the android official documents or read this if you are new to this concept. To explain it in brief, EncryptedSharedPreferences is kind of a wrapper on top of SharedPreferences. Additionally, it does perform an encryption and decryption operation while storing and fetching the values from shared preferences. It is included in the androids Jetpack security library and you can find it in package - ‘androidx.security.crypto’. Now, let’s go little deep to see how does EncryptedSharedPreferences works internally.
How EncryptedSharedPreferences works internally?
Jetpack Security has two types of keys, i.e. master key and subkeys. The subkeys are used to perform an encryption operation on the actual data and the master key is used to encrypt all subkeys. This has been done to add an extra security layer.
The master key is stored in the AndroidKeystore whereas subkeys are encrypted and stored with the shared preferences itself. If you are using the EncryptedSharedPrefrance in your app, then you can see a file with name {$shared_pref_file_name}.xml in your app’s internal directory where you can see the encrypted subkeys with following alias:
_androidx_security_crypto_encrypted_prefs_key_keyset_ and _androidx_security_crypto_encrypted_prefs_value_keyset_
Okay, this is cool.. but how secure is it?
To keep something really secure, we need to limit the access to the encryption keys because those are used for encryption and decryption operation. Jetpack Security uses Android Keystore to do this job.
The Android Keystore system lets you store the cryptographic keys at specialized secure hardware to make it very hard to extract them out from the device. Your app has access to those keys but it doesn’t know what the exact key content is. Keys are generated within the secure hardware, then they are used to perform cryptographic operations on user data without the keys ever leaving the secure hardware. It is not possible to extract the keys stored in that secure hardware in an easy way. So yes, your secret key will be very safe, even on a rooted device.
Additionally, it uses the Advanced Encryption Standard (AES) which is one of the most secure things that you can use on Android. And hence, it is really very secure and safe way to manage your app’s sensitive master secrets if you are working on the Non-system Apps.
Warning: Are you using sharedUserId= “android.uid.system” in your app’s manifest file?
If you have a system app and using a sharedUserId= “android.uid.system” in the android manifest file, then you are in trouble
‘‘According to my observation, if we do a “clear data” action of any system app (which uses sharedUserId=‘android.uid.system’), then it will clear the instance of Android keystore. Now all other apps who has stored the sensitive data and secret keys with android key store(and using same sharedUserId), will loose all their data. ”
Also, for all other system apps who have stored their data with Encrypted Shared Preferences will not be able decrypt the data back because MasterKeys would have be blown away with clear data action. Ooh my god!!! Isn’t it a serious issue?
I did not find any official documents to support this theory, but I find the similar bug here which got closed without resolving. Also checkout the above video to get the detailed demonstration.
Currently, if you are also facing the same issue with your app, then other than managing the secret keys by your own, I do not see any other good and secure alternative. Fill free to give the suggestions if you have any better approaches in mind. I will also update this blog as soon as I get any proper alternative for this issue. But for now we have keep this alert in our mind.
[Note: This issue is only applicable for the system apps and normal non system apps does not affect with this]
References: