App Manager uses a metadata file for each backups which contains a lot of information regarding the app. Besides, the folder itself contains metadata info such as package name and the user ID. If encryption is enabled, an adversary cannot modify the metadata file in any way (because it will result in verification failure), but they still can gather a lot of information regarding the apps a user has, even the app list is often considered a valuable metadata. To fix the issues, a novel scheme has been proposed:
The metadata file will be divided into two separate files:
info.json: This unencrypted but verifiable file will contain encryption information and backup flags.
meta.json: This file will contain all the other information and will be encrypted like the other files.
In addition, UUID will be used for folders instead of package names to prevent collection of backed up packages by a potential adversary. Backups will no longer be stored in the sub folders with <user_id>_<backup_name> format. Consequently, a key will be added in the meta.json and the version number will be incremented:
backup_name: Backup name/label. Having the backup name stored as a metadata also has the benefit of using any names.
All in all, the following metadata will be stored in the info.json, which will be visible to everybody:
version: Metadata version
backup_name: Name of the backup, could be empty
backup_time: When the backup was made
flags: Backup flags
crypto: Encryption type
iv/aes/keyIds: Additional info for crypto
checksum_algo: Checksum algorithm used to verify the backups
user_handle: The user ID to which the backup originally belonged
Backward compatibility
As usual, backward compatibility will be provided for old backups. However, there will not be any option to convert them to the new format due to its complexity.
App Manager uses a metadata file for each backups which contains a lot of information regarding the app. Besides, the folder itself contains metadata info such as package name and the user ID. If encryption is enabled, an adversary cannot modify the metadata file in any way (because it will result in verification failure), but they still can gather a lot of information regarding the apps a user has, even the app list is often considered a valuable metadata. To fix the issues, a novel scheme has been proposed:
The metadata file will be divided into two separate files:
info.json: This unencrypted but verifiable file will contain encryption information and backup flags.meta.json: This file will contain all the other information and will be encrypted like the other files.In addition, UUID will be used for folders instead of package names to prevent collection of backed up packages by a potential adversary. Backups will no longer be stored in the sub folders with
<user_id>_<backup_name>format. Consequently, a key will be added in themeta.jsonand the version number will be incremented:backup_name: Backup name/label. Having the backup name stored as a metadata also has the benefit of using any names.All in all, the following metadata will be stored in the
info.json, which will be visible to everybody:version: Metadata versionbackup_name: Name of the backup, could be emptybackup_time: When the backup was madeflags: Backup flagscrypto: Encryption typeiv/aes/keyIds: Additional info for cryptochecksum_algo: Checksum algorithm used to verify the backupsuser_handle: The user ID to which the backup originally belongedBackward compatibility As usual, backward compatibility will be provided for old backups. However, there will not be any option to convert them to the new format due to its complexity.