0

I'm implementing backup in my app, following the instructions in the official Android documentation. The information I'm backing up is potentially sensitive, so I'd like to encipher it, as per the recommendation in the above document:

You should always be cautious about using backup to store sensitive data, such as usernames and passwords.

The recommended approach to ciphering user data, of generating a random key when needed, and storing it, doesn't help in the backups case, because if I'm restoring a backup, the generated key has probably been lost (or would have to be included in the backup). Similarly, I can't use any device identifier (such as the IMEI) to generate a deterministic key, because the backup might legitimately be restored onto a different device.

Asking the user for a passphrase to secure the key would work across devices, but onRestore is done entirely in the background. To get a passphrase from the user, I'd have to save the ciphertext to storage, make a note for next time my main activity is started, and prompt the user then. Apart from that faff, I don't really believe the user is going to enter a passphrase once, never use it again until the restore happens, potentially years later, and then be able to remember it. I wouldn't! And then there'd be no way to restore the backup, and I might as well not have implemented backup at all.

It seems like the only reasonable option is to have a fixed key that's stored in my APK, but I'm sure I don't have to explain here why that doesn't really provide any extra security. I'd consider it if I were only storing secrets to internal storage, but anyone who can install a dodgy backup transport on the device, or illicitly access the backup server, wouldn't be inconvenienced by having to decompile or inspect the app.

Can anyone offer me a better option?

Dan Hulme
  • 14,779
  • 3
  • 46
  • 95
  • If it is "potentially sensitive" enough that you want to encrypt the backup, you should be encrypting the original copy, IMHO, perhaps using SQLCipher for Android. Internal storage is reminiscent of the Maginot Line: looks impressive, will stop some things, but is easy enough to skirt around if you know what you're doing and have the right tech. And, having it encrypted at all times with a user-supplied passphrase means that backup/restore is more straightforward. – CommonsWare Mar 22 '13 at 17:12
  • That thought occurred to me. The stuff that's sensitive enough that the app won't tell it to the user (i.e. saved passwords) can just not be backed up, I think. I'm more thinking of data that the app will tell the user anyway. There's no reason to cipher it internally if you can just use the app to get it. But then maybe anyone who could read the backup could root the device anyway, and I'm being paranoid in the wrong places? – Dan Hulme Mar 22 '13 at 17:17
  • "There's no reason to cipher it internally if you can just use the app to get it." -- if you "cipher it internally", nobody can "just use the app to get it" without the passphrase (assuming that I am interpreting your "cipher it internally" statement correctly). Your primary alternative to keeping it encrypted all of the time is to not use `BackupManager`, but instead to give the user the ability to back up and restore the data as they see fit through your UI to external storage or "the cloud", perhaps encrypting it with a user-supplied passphrase at that point. – CommonsWare Mar 22 '13 at 17:20

0 Answers0