Misconception about filesystem-based encryption

grayway

FBE encryption on android devices does not properly protect user data in BFU state

We need to roll back to some sort of FDE encryption like it was on Samsung Galaxy S4 running KitKat or something like LUKS2 on Linux distrib

User installed apps names can be retrieved in BFU. If you don't disconnect WiFi or enable airplane before reboot it will auto-connect. Bluetooth does the same and you can clearly sees WiFi and Bluetooth devices automatically connecting without unlocking the phone at least once

All user related metadata must remained encrypted

It's not a problem if we have to encrypt the entire flash storage after a reset, flashlight not available, alarm not working or people can't calling

We don't need to have some device related functionality working in BFU, We need that black screen asking our pin or password to unlock the entire disk and that's it

GrapheneOS devs I'm extremely grateful for everything you did already to make android more secure and private. I did not see any real security software improvements in big companies over years. Android stock has still the 16 character maximum passcode length and no one gives a fuck about giving us a proprely secured and private device

de0u

grayway We don't need to have some device related functionality working in BFU, We need that black screen asking our pin or password to unlock the entire disk and that's it

Potentially of interest:

ryrona

grayway FBE encryption on android devices does not properly protect user data in BFU state

We need to roll back to some sort of FDE encryption like it was on Samsung Galaxy S4 running KitKat or something like LUKS2 on Linux distrib

The encryption on Android including GrapheneOS isn't pure file-based encryption. All blocks containing file data are encrypted with the credentials, passphrase or PIN, of the current user profile, but all other blocks holding metadata are also encrypted, with a "device key", that is residing in the secure element, but theoretically can be extracted from there.

GrapheneOS developers have expressed interest in making the metadata encryption be protected with user-provided credentials too, which would protect the list of installed apps, as well as file metadata such as number of files per folder and file sizes too in BFU. The file-based encryption would in that case not be replaced, since it is useful to allow keeping file data for not-logged-in user profiles protected. Instead, credentials will be added to the metadata encryption too.

It is unclear how this will be implemented, and it might be quite a bit of work. And as far as I have understood, it is not prioritized currently.

Knowing what apps one have installed can be a problem in itself, the apps might be illegal in the country you are in, or may strongly imply who you are. Likewise, file sizes alone, even in locked user profiles, can reveal what documents or files it is you have stored in that user profile, since file sizes often are unique. I hope we will see credential based encryption of metadata too in the future. Ideally, each user profile would have its own file system with regular full disk encryption, in thinly provisioned partitions. That would protect metadata of not running user profiles in AFU too. But that might be too much to ask for.

GrapheneOS

grayway You're wrong about how the disk encryption works. Android uses filesystem-based full disk encryption, contrary to your belief that it only encrypts files. All of the data and metadata is encrypted. There's no reason there can't be a prompt at boot requesting the Owner PIN/passphrase to use it for the device encrypted data. Please read https://grapheneos.org/faq#encryption and do basic research before you make posts making extraordinary claims next time.

We need to roll back to some sort of FDE encryption like it was on Samsung Galaxy S4 running KitKat or something like LUKS2 on Linux distrib

This is a far less secure approach unable to have per-profile encryption keys and put data back at rest. You're wrongly conflating things together.

GrapheneOS

grayway

Android stock has still the 16 character maximum passcode length and no one gives a fuck about giving us a proprely secured and private device

A randomly generated mixed case alphanumeric passphrase with 16 characters has over 95 bits of entropy which is more than good enough even without the secure element throttling and hardware-bound key derivation. It's just not very super practical for most people to remember that and quickly enter it. It's nicer to only use lowercase letters and digits without mixed case, which drops it down to over 82 bits of entropy. Needs to be increased to 18 characters to be over 93 bits of entropy. There's also no way to use secure diceware passphrases with that length limit, which is the main thing we enable by using a very high limit. 16 characters does not prevent having a highly secure > 90 bit entropy passphrase but it does greatly limit the options.

Also worth noting that a device management app including an entirely local one can raise the limit from 16 characters with standard Android. It's not hard-wired to 16 but rather that's what they set as a default limit for unclear reasons. There's no particular reason for them not raising it to 64 or higher, they just haven't done it yet.

Most people aren't going to set a strong passphrase and the encryption doesn't depend on it to provide working encryption due to the secure element integration. Most users are going to rely on the secure element throttling for security regardless of the theoretical password length limit. Supporting 128 character passwords as GrapheneOS does doesn't mean any significant number of users are going to use more than a 6-8 digit PIN or weak passphrase. Our 2-factor fingerprint authentication feature does greatly increase the likelihood of people choosing to use a strong passphrase as their primary unlock method since it doesn't entirely destroy the convenience of using the OS.

Upstate1618

ryrona some apps need direct boot. Phone is different from computers.

GrapheneOS

ryrona ryrona

All blocks containing file data are encrypted with the credentials, passphrase or PIN, of the current user profile,

The blocks containing file data and the filenames are encrypted with the per-profile keys. It's also done for other kinds of profiles like a Private Space.

ryrona Instead

but all other blocks holding metadata are also encrypted, with a "device key", that is residing in the secure element, but theoretically can be extracted from there.

There's no key stored in the secure element or elsewhere for this. It doesn't really matter, but it is not how it works. It's already set up in a way that there could be a boot passphrase, there just isn't one and it would be a lot of work to come up with a system for doing that. It's a planned feature for the future when we have more resources and early access to major Android releases so we can port our changes before the new release comes out instead of quickly doing it after it's released, which is increasingly hard with a growing amount of changes. 2-factor fingerprint authentication has already greatly increased the difficulty, as does the sandboxed Google Play compatibility layer.

Ideally, each user profile would have its own file system with regular full disk encryption, in thinly provisioned partitions. That would protect metadata of not running user profiles in AFU too. But that might be too much to ask for.

This would be an incredibly invasive overhaul. It's not something that we're realistically going to implement. Implementing a boot passphrase prompt for requesting the Owner user PIN/passphrase would already be very invasive and difficult to maintain. It would already involve changing the disk format which is a risky thing to do since we wouldn't be able to drop support for it if we couldn't get it ported to a new version. Doing that could be the end of GrapheneOS as as a serious option if we failed to migrate to a new version and therefore it would have to be done with extreme caution...

grayway2

GrapheneOS As of today not all metadata related to userdata are encrypted. A mobile device forensic analyst can retrieve installed list apps or see files size which is enough on some authoritarian regimes to put you behind bars.

I definitely misunderstood how filesystem based encryption works on Android, however the problem is still there and the problem is of course not the encryption but what is encrypted

Upstate1618

GrapheneOS
Is there any method for you to gain early access again? I know your access was revoked.

ryrona

GrapheneOS There's no key stored in the secure element or elsewhere for this.

Really? So a factory reset won't securely wipe metadata?

I just assumed AOSP at least did that. Even SSD and NVME disks for computers are expected to do such an operation to cryptographically destroy all data when running Secure Erase.

If that is the case, the problems with metadata not being encrypted with credentials is even worse, as any future owner of the device can identify what apps and files you had on your phone, and it is also possible for a physical attacker to identify this after using the duress functionality, limiting its use quite a bit too.

Upstate1618

grayway2
You are wrong. All user data and related metadata is encrypted in GrapheneOS. some data is encrypted in a less secure way than others. A boot passphrase can make it more secure that forensic company cannot extract it in BFU.

GrapheneOS

grayway2 All data and metadata is encrypted. There isn't a block of data or metadata that's not encrypted. The keys used for data and file names in profiles are protected by their lock methods. They're per-profile keys. The keys used for metadata blocks and the small amount of data outside of profiles are not protected by a profile's lock method but that doesn't mean they can't be protected with the Owner user lock method via a boot passphrase in the future.

GrapheneOS

ryrona

Really? So a factory reset won't securely wipe metadata?

No, a factory reset will securely wipe all the data and metadata. Your misunderstanding is that you believe the hardware integration involves storing an encryption key in the secure element. That's not how it works.

I just assumed AOSP at least did that. Even SSD and NVME disks for computers are expected to do such an operation to cryptographically destroy all data when running Secure Erase.

If that is the case, the problems with metadata not being encrypted with credentials is even worse, as any future owner of the device can identify what apps and files you had on your phone, and it is also possible for a physical attacker to identify this after using the duress functionality, limiting its use quite a bit too.

There is no issue with wiping device encrypted data reliably. It's reliably wiped in multiple ways. It just doesn't work the way you believe it does.

grayway2

GrapheneOS i'm exactly talking about that data outside of profiles that are currently not protected despite not really understanding where it is located. I never said that file names are not encrypted. I talked about names of installed apps or the size of files. If the boot passphrase isn't something very resourceful to code, I really hope that you and the others devs could add this in a near future

ryrona

From https://grapheneos.org/faq#encryption:

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. [...] 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.

I found no informtion on Android developer website related to this, GrapheneOS website is the only one that even talks about reliable wiping of data.

GrapheneOS No, a factory reset will securely wipe all the data and metadata. Your misunderstanding is that you believe the hardware integration involves storing an encryption key in the secure element. That's not how it works.

Could you clarify how reliable wiping of metadata is done?

As I understand your response, there isn't a weaver token for the metadata encryption key (device encryption key)? In that case I wonder how reliable wiping of metadata is implemented, as TRIM operations to the flash memory are not considered reliable wiping, so there must exist some kind of value or token that is part of the key derivation process that is stored on some securely erasable memory for reliable wiping of metadata to be possible.

Or you mean a weaver token is being used for the device encryption key too? You are just marking at my simplified description of the encryption key itself being stored in the secure element? In that case I wonder what the conditions are for the secure element to release that weaver token. For credential-based encryption keys, a hash of the credentials needs to be supplied for the weaver token to be released. For the device encryption key, is it enough to supply a well-known or empty value to release the weaver token? Or is it conditioned on a successful verified boot against an authenticated CPU, as it is (supposedly) implemented in some other operating systems?

I hope you feel you can take the time to explain this, as my understanding of how the disk encryption layer of Android and GrapheneOS works is obviously lacking, and there doesn't really seem to be any documentation or other reliable information on the web about this. I just want to be able to understand what level of privacy against local attackers I really have in various scenarios. It might matter quite a bit to me in my threat model.