File and disk encryption
Any data your app stores should in general be encrypted. This is even true for data stored on internal storage, as physical access to an Android device by an attacker could allow them to dismantle the phone and extract the data.
Full-Disk Encryption: from Android 5.0 full-disk encryption is supported. With full-disk encryption all the data on the device is encrypted with the same key, and the key itself is protected by the user’s password.
File-Based Encryption: from Android 7.0 file-based encryption is supported. With file-based encryption different files can be encrypted with different keys. This means some files can be decrypted whilst others remain encrypted, which can both improve security and improve usability.
Whether a particular device supports either full-disk or file-based encryption is dependent upon the manufacturer.
File-based encryption also provides something called Direct Boot.
Under full-disk encryption, because all the data on the device is encrypted with the same key, and that key is protected by the user’s password, after rebooting the device cannot access any data until the user enters their password.
This means things like alarms do not work until the user has entered their password. Direct Boot provides a solution to this problem.
Storage on a device supporting file-based encryption (Android 7.0 - API level 24 onwards) is partitioned into two areas:
Credential Encrypted Storage: this is only accessible after the user has entered their password. This is the default storage area. The data in this are is encrypted, and the key is protected by the user’s password.
Device Encrypted Storage: this is available before (and after) the user has entered their password. The data in this area is encrypted. To access the key the device must perform a successful verified boot.
When a device first boots it enters Direct Boot mode and only has access to the device encrypted storage.
In Direct Boot mode app components can only run if they have registered that they need to be able to run in that mode. A component can register by setting the attribute
in the component’s entry in the
The system broadcasts three different messages during the boot process to indicate the transitions between the different modes:
ACTION_LOCKED_BOOT_COMPLETED: broadcast when the device is rebooted and enters Direct Boot mode. Device encrypted storage is available when this message is broadcast, but credential encrypted storage is not.
ACTION_USER_UNLOCKED: broadcast when the user unlocks the device after a reboot. Both credential and device encrypted storage are available. This action is intended for foreground processes that need to know that the device has been unlocked immediately.
ACTION_BOOT_COMPLETED: broadcast when the user unlocks the device after a reboot. Both credential and device encrypted storage are available. This action is intended for background processes that can wait to be notified that the device has been unlocked.
An app can register one or more Broadcast Receivers that listen for these mode changes (by adding the appropriate Intent Filters to the app’s
In order to access device encrypted storage (i.e. to read and write files etc) a component can call
createDeviceProtectedStorageContext() to create a Context instance that directs the standard file API calls to the device encrypted storage area (the default storage area is credential encrypted storage).
A component can also call
isUserUnlocked() to determine if the device has been unlocked.
© University of Southampton 2017