diff options
| author | Christopher Tate <ctate@google.com> | 2011-07-19 16:32:49 -0700 |
|---|---|---|
| committer | Christopher Tate <ctate@google.com> | 2011-07-28 16:01:20 -0700 |
| commit | 2efd2dbbac9eac89620683696c6076463c3a1cd6 (patch) | |
| tree | ca48adf4208daee43a4444a0fdb61fcb939858c5 /packages/BackupRestoreConfirmation/res/values | |
| parent | b7d95a46dfacf04896d5b084f13bcbe6eab33633 (diff) | |
| download | frameworks_base-2efd2dbbac9eac89620683696c6076463c3a1cd6.zip frameworks_base-2efd2dbbac9eac89620683696c6076463c3a1cd6.tar.gz frameworks_base-2efd2dbbac9eac89620683696c6076463c3a1cd6.tar.bz2 | |
Support full-backup encryption and global backup password
If the user has supplied a backup password in Settings, that password
is validated during the full backup process and is used as an encryption
key for encoding the backed-up data itself. This is the fundamental
mechanism whereby users can secure their data even against malicious
parties getting physical unlocked access to their device.
Technically the user-supplied password is not used as the encryption
key for the backed-up data itself. What is actually done is that a
random key is generated to use as the raw encryption key. THAT key,
in turn, is encrypted with the user-supplied password (after random
salting and key expansion with PBKDF2). The encrypted master key
and a checksum are stored in the backup header. At restore time,
the user supplies their password, which allows the system to decrypt
the master key, which in turn allows the decryption of the backup
data itself.
The checksum is part of the archive in order to permit validation
of the user-supplied password. The checksum is the result of running
the user-supplied password through PBKDF2 with a randomly selected
salt. At restore time, the proposed password is run through PBKDF2
with the salt described by the archive header. If the result does
not match the archive's stated checksum, then the user has supplied
the wrong decryption password.
Also, suppress backup consideration for a few packages whose
data is either nonexistent or inapplicable across devices or
factory reset operations.
Bug 4901637
Change-Id: Id0cc9d0fdfc046602b129f273d48e23b7a14df36
Diffstat (limited to 'packages/BackupRestoreConfirmation/res/values')
| -rw-r--r-- | packages/BackupRestoreConfirmation/res/values/strings.xml | 7 |
1 files changed, 7 insertions, 0 deletions
diff --git a/packages/BackupRestoreConfirmation/res/values/strings.xml b/packages/BackupRestoreConfirmation/res/values/strings.xml index 3d85e86..48a8df6 100644 --- a/packages/BackupRestoreConfirmation/res/values/strings.xml +++ b/packages/BackupRestoreConfirmation/res/values/strings.xml @@ -29,4 +29,11 @@ <!-- Button to refuse to allow the requested full restore --> <string name="deny_restore_button_label">Do not restore</string> + <!-- Text for message to user that they must enter their predefined backup password in order to perform this operation. --> + <string name="backup_password_text">Please enter your predefined backup password below. The full backup will also be encrypted using this password:</string> + <!-- Text for message to user that they may optionally supply an encryption password to use for a full backup operation. --> + <string name="backup_password_optional">If you wish to encrypt the full backup data, enter a password below:</string> + + <!-- Text for message to user when performing a full restore operation, explaining that they must enter the password originally used to encrypt the full backup data. --> + <string name="restore_password_text">If the backup data is encrypted, please enter the password below:</string> </resources> |