Graphene OS Phone Encryption

How is disk encryption implemented?

Graphene OS uses an enhanced version of the modern filesystem-based disk encryption implementation in the Android Open Source Project. The officially supported devices have substantial hardware-based support for enhancing the security of the encryption implementation. GrapheneOS has full support for the hardware-based encryption features just as it does with other hardware-based security features.

Firmware and OS partitions are identical copies of the images published in the official releases. The authenticity and integrity of these partitions is verified from a root of trust on every boot. No data is read from any of these images without being cryptographically verified. Encryption is out of scope due to the images being publicly available. Verified boot offers much stronger security properties than disk encryption. Further details will be provided in another section on verified boot in the future.

The data partition stores all of the persistent state for the operating system. Full disk encryption is implemented via filesystem-based encryption with metadata encryption. All data, file names and other metadata is always stored encrypted. This is often referred to as file-based encryption but it makes more sense to call it filesystem-based encryption. It's implemented by the Linux kernel as part of the ext4 / f2fs implementation rather than running a block-based encryption layer. The advantage of filesystem-based encryption is the ability to use fine-grained keys rather than a single global key that's always in memory once the device is booted.

Disk encryption keys are randomly generated with a high quality CSPRNG and stored encrypted with a key encryption key. Key encryption keys are derived at runtime and are never stored anywhere.

Sensitive data is stored in user profiles. User profiles each have their own unique, randomly generated disk encryption key and their own unique key encryption key is used to encrypt it. The owner profile is special and is used to store sensitive system-wide operating system data. This is why the owner profile needs to be logged in after a reboot before other user profiles can be used. The owner profile does not have access to the data in other profiles. Filesystem-based encryption is designed so that files can be deleted without having the keys for their data and file names, which enables the owner profile to delete other profiles without them being active.

Graphene OS enables support for ending secondary user profile sessions after logging into them. It adds an end session button to the lockscreen and in the global action menu accessed by holding the power button. This fully purges the encryption keys and puts the profiles back at rest. This can't be done for the owner profile without rebooting due to it encrypting the sensitive system-wide operating system data.

Using a secondary profile for regular usage allows you to make use of the device without decrypting the data in your regular usage profile. It also allows putting it at rest without rebooting the device. Even if you use the same passphrase for multiple profiles, each of those profiles still ends up with a unique key encryption key and a compromise of the OS while one of them is active won't leak the passphrase. The advantage to using separate passphrases is in case an attacker records you entering it.

File data is encrypted with AES-256-XTS and file names with AES-256-CTS. A unique key is derived using HKDF-SHA512 for each regular file, directory and symbolic link from the per-profile encryption keys, or the global encryption key for non-sensitive data stored outside of profiles. The directory key is used to encrypt the file names. Graphene OS increases the file name padding from 16 bytes to 32 bytes. AES-256-XTS with the global encryption key is also used to encrypt filesystem metadata as a whole beyond the finer-grained file name encryption.

The OS derives a password token from the profile's lock method credential using scrypt. This is used as the main input for key derivation.

The OS stores a high entropy random value as the Weaver token on the secure element (Titan M on Pixels) and uses it as another input for key derivation. The Weaver token is stored alongside a Weaver key derived by the OS from the password token. In order to retrieve the Weaver token, the secure element requires the correct Weaver key. A secure internal timer is used to implement hardware-based delays for each attempt at key derivation. It quickly ramps up to 1 day delays before the next attempt. Weaver also provides reliable wiping of data since the secure element can reliably wipe a Weaver slot. Deleting a profile will wipe the corresponding Weaver slot and a factory reset of the device wipes all of the Weaver slots. The secure element also provides insider attack resistance preventing firmware updates before authenticating with the owner profile.

Standard delays for encryption key derivation enforced by the secure element:

• 0 to 4 failed attempts: no delay

• 5 failed attempts: 30 second delay

• 6 to 9 failed attempts: no delay

• 10 to 29 failed attempts: 30 second delay

• 30 to 139 failed attempts: 30 × 2⌊(n - 30) ÷ 10⌋ where n is the number of failed attempts. This means the delay doubles after every 10 attempts. There's a 30 second delay after 30 failed attempts, 60s after 40, 120s after 50, 240s after 60, 480s after 70, 960s after 80, 1920s after 90, 3840s after 100, 7680s after 110, 15360s after 120 and 30720s after 130

• 140 or more failed attempts: 86400 second delay (1 day)

Invalid input outside the minimum or maximum length limits of the UI won't trigger an attempt at authentication or key derivation.

Graphene OS only officially supports devices with Weaver. The fallback implementation for devices without it is out-of-scope for this FAQ.

The password token, Weaver token and other values like the OS verified boot key are used by the TEE as inputs to a hardware-bound key derivation algorithm provided by the SoC. The general concept is having the SoC perform hardware accelerated key derivation using an algorithm like AES or HMAC keyed with a hard-wired hardware key inaccessible to software or firmware. This is meant to prevent offloading a brute force attack onto more powerful hardware without an expensive process of extracting the hardware key from the SoC.

Many apps use the hardware keystore, their own encryption implementation or a combination of those to provide an additional layer of encryption. As an example, an app can use the hardware keystore to encrypt their data with a key only available when the device is unlocked to keep their data at rest when the profile is locked but not logged out. This is beyond the scope of this article.

— Graphene OS Development Team