Android supports cloud and local backup of APK files, application data, and so on. Is the device keystore included in the backup?
(I don't think you can extract private keys from an hardware-backed keystore even in rooted devices, not so sure about the software-based version used when there is no hardware support.)
No. The whole point behind the hardware-backed keystore is that it's resistant to even privileged attacks with root access.
For this reason, not even the OS can access raw key material from the hardware-backed keystore.
While it would be theoretically possible for the OS to do a keystore backup on lower end devices with a software-backed keystore, this is simply not done or allowed by the OS for security reasons.
You cannot back up the Keystore, so when your encrypted data will be restored you won't be able to decrypt it.
You have to find a different way to backup data, for example:
Store user data one backend
Use a user-stored token to decrypt the backup
Have a static password for all apps
Export backup manually by the user in settings
I wrote about it more here:
https://medium.com/#thecodeside/android-auto-backup-keystore-encryption-broken-heart-love-story-8277c8b10505
A July 13 2016 check with official says no:
"What gets backed up with Android Backup Service
Google Calendar settings
Wi-Fi networks & passwords
Home screen wallpapers
Gmail settings
Apps installed through Google Play (backed up on the Play Store app)
Display settings (Brightness & Sleep)
Language & Input settings
Date & Time
Third-party app settings & data (varies by app)
Note: Not all apps use Android Backup Service. Some apps may not back up and restore all data."
Of course backing up and restoring apps that use the KeyStore without the KeyStore itself being backed up and restored with the account makes little or no sense.
Though it's possible they did not update their docs my best guess is that the KeyStore is backed up but that information is not made widely available.
Possibly due to the backup not being encrypted prior to transport which is the Google back up standard. They may have made an exception for the keystore but that would indicate all other data isn't as secure when transported nor when received by their servers (they do encrypt the data once they receive it).
Related
We're implementing a loginless system on our web, iOS, and Android app that allows the user to have a persistent identity without requiring any sign-up/sign-in flows whatsoever.
A key part of loginless is relying on iOS and Android to permanently store our app's data in the user's iCloud / Google account so that the data is automatically restored for the user in each of the scenarios:
(i) Quitting and re-opening the app (accomplished with SharedPreferences in Android, UserDefaults in iOS)
(ii) Uninstalling and re-installing the app on the same device (accomplished with key/value backup in Android¹, Keychain + NSUbiquitousKeyValueStore in iOS)
(iii) Setting up a new device based on a backup of an old device (accomplished with key/value backup in Android¹, UserDefaults + Keychain + NSUbiquitousKeyValueStore in iOS)
(iv) Installing the app on a brand new device signed into the same iCloud / Google account that the user previously used the app with (accomplished with NSUbiquitousKeyValueStore in iOS)
The only case we have remaining is figuring out how to accomplish (iv) for Android. Does key/value backup in Android restore the data in this case, even when the brand new device wasn't set up from a backup of an older device?
We've discovered the existence of Cloud Firestore and AccountManager during our research, but it seems like the data in Cloud Firestore is keyed on an device basis so it wouldn't accomplish (iv), and it seems like AccountManager requires asking permission from the user to ask for their accounts via android.permission.GET_ACCOUNTS, plus the whole design of loginless is intended not to ask the user for any personally identifiable information. Are we correct in these conclusions, or could Cloud Firestore be used to accomplish (iv)? Is there anything else we can use to accomplish (iv) in Android?
¹ We decided to use key/value backup instead of auto backup because the frequency of backups is greater than that of auto backups. See more information on the difference in Android's documentation.
Shared preferences should restore from the previous device if the android:allowBackup attribute is set to true. As far as I know this works if you have your phone backed up at Google (Drive).
Regarding the IV point, previous to 2018 you could use the now-depracted Android Drive Api, but currently you can use the Drive API v3 to enable an app to use the customer space in their drive to store application-specific data.
This folder is only accessible by your application
and its contents are hidden from the user and from other Drive apps.
I'm currently looking at the possibilities of storing/using secrets keys in an Android application. I've found Nikolay Elenkov's blog very helpful regarding this topic and I've learnt a lot of things about the Android keystore and some hardware-based implementations.
Still I've got some questions about security and user experience aspects.
Software keystore
For what I understood, in this configuration a masterkey is derived (using PBKDF2) from a user password (plus a salt to prevent rainbow tables attacks) and used to encrypt secrets. As far as I know, the password is the one used for the lock screen.
On a non-rooted phone, only the user 'keystore' is able to read/write the encrypted files and whenever an application want to access a file, it has to call the keystore daemon which checks if its UID is authorized to access this file (the authorizations are stored in a sqlite database).
But there are still some details I couldn't figure out :
Does using the keystore enforce the use of a password-protected lock screen ?
Does the user have to input his/her password every time an access to the encrypted keys is required ?
Given it's a software-only mechanism, I think a secret key will always end up decrypted in RAM whenever it's used for cryptographic operations, right ?
Hardware-based keystore
As for the hardware-based implementation, it seems that SoC manufacturers provide solutions compliant to [Global Platform TEE][2] (Trusted Execution Environment) with embedded Trusted Applications and APIs that enable Google to provide an hardware-backed implementation of its keystore. It's thus possible to store secret keys in the TEE, ask for RSA key pair creation inside the TEE and sign or check data using secret keys stored inside the TEE. This way, one can use secret keys for basic cryptographic operations without them ever leaving the TEE.
If I got it right, access control to those keys is provided by the Google keystore daemon using the same mechanism as in the software implementation. The only difference is that references to the keys stored in the TEE are used instead of the encrypted keys themselves.
If everything stated before is correct, I guess it would be possible on a rooted phone to modify the permissions database so that an application with an arbitrary UID can have data signed with any key stored in the TEE. Am I right ?
Thanks for your time!
Does using the keystore enforce the use of a password-protected lock
screen ?
Yes, user is forced to use lock screen, protected with password, pin, or pattern.
Does the user have to input his/her password every time an access to
the encrypted keys is required ?
No, once the device is unloked, KeyStore becomes unlocked as well and there's no need to enter additional passwords. However, application should check if the KeyStore is unlocked, because user could disable the lock screen protection in Settings. Once key locked is disabled, KeyStore becomes uninitialized and must be unlocked again.Several times I faced a strange behavior, when the KeyStore was locked, but I didn't have lock screen protection set up. I was prompted to enter a password or pin code to enter the KeyStore. However, it was not possible, since I didn't have any passwords. I assume some system apps were locking the KeyStore. I had to reset it to re-initialize.
Given it's a software-only mechanism, I think a secret key will
always end up decrypted in RAM whenever it's used for cryptographic
operations, right ?
Yes, all keys retrieved from the KeyStore will reside in RAM until garbage-collected or deinitialized. But you can obtain the key each time you need it, not keeping it in some long-living variable.
Unfortunately, I'm not familiar with HW-backed KeyStore. Cannot say anything about it.
Your analysis of the TEE-based hardware-backed scenario is correct. The private key bits generated in the TEE (which isn't necessarily compliant with the Global Platform specs) never leave the TEE and private key operations are performed inside it.
You're also correct that the handles to the TEE-based keys are stored in Keystore, so it's possible for root to access and use any of them, or to move them around so any app can use them.
Having a random key to encrypt local credentials through AES, I'm following the below tutorial to try to store securely that key and then be able to decrypt later on:
nelenkov.blogspot.co.uk storing applicationsecrets in androids
This tutorial explains how access to the system keystore and store your passwords in it.
The issue I'm facing it's focused in the call to UNLOCK (android.credentials.UNLOCK) the KeyStore. Devices (at the moment with API below 14) that don't have KeyStore initialized, they are showing a dialog requesting a 8 digits password.
The tutorial works fine however showing this dialog even do being only once, it's going to bother most of the users.
are there any way to skip this dialog?
I would be even happier if someone described a better way to keep locally a Key.
KeyStore can appear locked not only on pre-ICS devices. The simplest way to get KeyStore locked is:
Initialize KeyStore by setting KeyGuard (pattern, pin, or
password on the Screen Lock)
Add keys or whatever you store in the KeyStore
Go to Settings > Security and change Screen Lock to something "not
secure", for example, Slide.
Reboot your device.
After the device is booted, KeyStore will be LOCKED. com.android.credentials.UNLOCK intent will start com.android.settings.CredentialStorage activity, which, in turn, will show UnlockDialog, prompting for a password.
* KeyStore: LOCKED
* KeyGuard: OFF/ON
* Action: old unlock dialog
* Notes: assume old password, need to use it to unlock.
* if unlock, ensure key guard before install.
* if reset, treat as UNINITALIZED/OFF
KeyStore gets reset after 5 attempts to enter incorrect password. But resetting KeyStore actually doesn't turn it off or uninitialize. KeyStore remains locked and the only way to uninitialize it seems to call for com.android.credentials.RESET. But this will reset both KeyStore and KeyChain (user installed certificates).
If you want to reset KeyStore and KeyChain silently, without user confirmation, you can do it by binding to IKeyChainService and calling its reset() method. But I'd not recommend doing this. A better solution could be to display some notification message asking user to set Screen Lock manually
The 8 digit password is enforced by the your custom device firmware or a device administrator. There is no such requirement on most devices. If want to store something securely, you have to have a PIN code, Android uses it to derive the encryption key. Other options are to derive a key from your input yourself: you get to control the timing of dialogs and caching of keys, but it's the same process. Finally, you can just generate a master key and store it as a private file, other apps won't be able to read it, so you'll be fine on non-rooted devices. This is the approach recommended on the Android Developers Blog:
http://android-developers.blogspot.jp/2013/02/using-cryptography-to-store-credentials.html
When a user has paid for a premium subscription app what happens to the activation code if that device is then factory wiped? It cannot be stored in SharedPreferences - what about Google Play? I've noticed some apps are able to recover the activation codes after factory wipes. How is this possible?
Most likely because they are stored in the cloud, at their servers, and when you reconnect with a recognized account they know it. That recognized account may as well be the Google-account. Windows 8 metro comes for instance with their own cloud-based storage for applications linked to peoples live-accounts
Also some apps may store an activation-file on the SD-card or to file. Factory swipe does not always mean a formatting.
The shared preferences can be backed-up and restored to Google's cloud, or more specifically:
https://developers.google.com/android/backup/
Am installing certificate(.pk12) in my galaxy s2 from settings.After installing it shows toast " installed ". After that in my code am opening "/system/etc/security/cacerts.bks" key store and from it i can see number of aliases in keystore is 44 .Regardless of how many number of certificates I install the aliases count does not change. I doubt whether the installed certificates go to this key store itself.How do I confirm it?
Which key store should I read to see the installed certificates.
You cannot do what you're trying to do, unless you root the phone. Importing certificates using the standard interface (settings) only allows you to import certificates for VPN or Wi-Fi connections. To actually modify the system store (cacerts.bks), a system update from the manufacturer must be made to implement the new cacerts.bks file.
Details here:
http://code.google.com/p/android/issues/detail?id=11231#c25
If you root the phone, you can directly modify cacerts.bks, but stock Android does not permit this operation.