Questions about Private Space in main user profile

OrangeMamba

Unfortunately, I'm not particularly technically gifted, but I really want to know something.

Is the private space under the main user in Android programming a separate user, only that we don't see it?

Is the private space double encrypted, i.e. when I turn off my phone and it is in BFU mode? So first encryption layer of the main user and then, assuming the private space has its own independent password, the second layer?

Wouldn't it be safer to use the main user only for app updates and the private space for everyday tasks?

My particular focus is on double encryption.

Delaney

OrangeMamba Is the private space under the main user in Android programming a separate user

Yes

OrangeMamba Is the private space double encrypted, i.e. when I turn off my phone and it is in BFU mode? So first encryption layer of the main user and then, assuming the private space has its own independent password, the second layer?

Yes. Bear in mind that after first unlock, locking the private space doesn't put the data into rest by default. You can configure it to end session on lock.

OrangeMamba Wouldn't it be safer to use the main user only for app updates and the private space for everyday tasks?

Maybe, but this wouldn't be practical because some settings and phone specific apps aren't in private space, such as the Phone and Messaging apps. You'd be forced to use the main user.

Probably9857

OrangeMamba So first encryption layer of the main user and then, assuming the private space has its own independent password, the second layer?

Delaney Yes.

This doesn't seem correct to me. My understanding is that each profile is encrypted independently. The requirement to unlock the owner before any secondary profile is a requirement of the OS, which is effectively enforced by the secure element.

If the secure element were successfully exploited, a profile with a weak password could be brute forced independently of the owner.

I'm not an expert though, so someone please correct me if this is wrong.

secrec

OrangeMamba So first encryption layer of the main user and then, assuming the private space has its own independent password, the second layer?

No, as others have mentioned, private space is just another user profile.

The confusing part is that the private space appears tied with the main profile. The reality is that it is a totally separate user profile that is loaded simultaneously and with bits of it merged with the running profile so that they can be run simultaneously.

Its kind of like running a linux executable using "sudo".

de0u

Probably9857 My understanding is that each profile is encrypted independently.

Yes. There is no "double encryption".

Probably9857 The requirement to unlock the owner before any secondary profile is a requirement of the OS, which is effectively enforced by the secure element.

Not really. The current operational requirement to unlock the owner profile first might change in a future Android release. That would increase the usability of tablets (e.g., by students in a classroom) and also would enable full "parental control" scenarios. The current operational requirement is exactly a current operational requirement, not part of the Android security architecture.

de0u

Probably9857 The part I disagreed with was "effectively enforced by the secure element" (Probably9857). I think it is "enforced" by only the OS. The OS is easier to exploit than the secure element, and the OS may change its behavior.

de0u

de0u To be clear, it seems unlikely that Google will ship a version of Android that allows directly logging in to private spaces. But a hypothetical exploit could bypass or trick the regular login system and make that possible. As long as each profile's encryption is independent, it is prudent for each profile with important information to have a strong key.

Probably9857

de0u The current operational requirement is exactly a current operational requirement, not part of the Android security architecture.

It seems like you're just using different (probably more precise) words to say what I said, or at least what I meant.

You seem to be making a distinction between an operational requirement (your term) and a requirement of the operating system (mine). I don't understand the point of that distinction.

Probably9857

de0u The part I disagreed with was "effectively enforced by the secure element"

OK, that makes more sense.

What I meant by that was that the secure element is what ultimately prevents the OS rules from being bypassed in the first place. If you could exploit the secure element, you don't need the OS - you just go straight to the file system.

Is that correct?

Probably9857

de0u I think it is "enforced" by only the OS. The OS is easier to exploit than the secure element,

True, but exploiting the OS wouldn't help you to access data in a profile that is at rest, would it? You'd still need to get key material from the SE, I think

Edit: on second thought, maybe I'm wrong about this.

de0u

Probably9857 What I meant by that was that the secure element is what ultimately prevents the OS rules from being bypassed in the first place.

The interplay between the parts of the system is too complicated for me to agree with that particular statement. My understanding is that the secure element does refuse to provide wrapped storage keys to a kernel that isn't signed by the right key. But that is not at all the same as the secure element enforcing, or even understanding, all of "the OS rules".

Probably9857 If you could exploit the secure element, you don't need the OS - you just go straight to the file system.

I don't think that's correct either. My understanding is that the user-data storage keys are random, protected by a key derived from internal protected state plus keying material entered when a profile is unlocked. So compromising the secure element would allow high-speed key derivation attempts, but the user input to key derivation (PIN or passphrase) would still need to be guessed. Project members have repeatedly indicated that a six-digit random PIN is plausible if the secure element is trusted, otherwise a random diceware passphrase is suggested. I don't think there is a "straight to the file system" path, even if the secure element is compromised.

The GrapheneOS explanation is here: https://grapheneos.org/faq#encryption