New security audit done, I found a Private Space encryption issue

thmf

DeletedUser313 Has this been changed?

Yes and no. See here.

dhhdjbd

thmf
Thanks, So do i understand correctly that it does not exist yet, because the toggle does not exist?

good that i saw this threaad because i thought private space would be encrypted when locked..

GrapheneOS

dhhdjbd The data is always encrypted. Data is not at rest after first unlock except when keys are explicitly purged from registers/memory such as via the end session feature for secondary users. Private Space supports secondary unlock via fingerprint which it couldn't do if it went fully to rest when locked after the first unlock. That's why we couldn't implement always doing this.

ryrona

dhhdjbd good that i saw this threaad because i thought private space would be encrypted when locked..

It is encrypted, but once unlocked after a phone reboot, the encryption key stays loaded. Reboot the phone to unload the key, only locking the private space is not enough yet. But if you reboot the phone, the private space data is fully encrypted and inaccessible.

Nobody123

Files in Private Space always seem to be stored with their own unique encryption key and their own weaver token, regardless whether you choose to use the same credentials or separate credentials when setting up the Private Space.

ryrona would this only apply to grapheneOS, or would it also apply to stock Android?

GrapheneOS

Nobody123 You have it backwards. It's a property of how it works on Android and GrapheneOS has provided a toggle to change how it works by putting it back at rest when locked. You're posting in an outdated thread. See https://grapheneos.org/releases#2025051900.

ryrona

Nobody123 would this only apply to grapheneOS, or would it also apply to stock Android?

Using separate encryption key and weaver token for the private space, regardless of shared credentials or not, is a feature coming from AOSP, and should thus be how it is implemented on stock too. GrapheneOS did not do any changes here from what I can tell.

Nobody123 Provided private space has not been unlocked since the last device reboot, it will be as difficult to unlock private space as it would be to unlock the device itself if the device were in BFU state.

If using separate passphrase, definitely, yes. If using the same one, theoretically, there is a slim chance the passphrase is still cached in some RAM memory somewhere, so theoretically possible to extract using software or physical exploits. It is not supposed to be cached, and GrapheneOS even goes out of the way to implement extra zero-on-free functionality to lower the risk further, but the keyboard and screen lock functionalities might not have properly zeroed or freed the space that held the input for the passphrase. In practice, attacks extracting passphrase that way is completely unheard of, and might be unrealistically hard to perform. But theoretically, the private space might be slightly easier for a skilled attacker to unlock once owner profile has been unlocked, if credentials are shared.

Nobody123 This holds even if: (1) the private space lock is the same as the device screen lock;

Yes, but see above.

Nobody123 (2) the device is stolen while the main space is unlocked

Yes.

Nobody123 ; and (3) stock Android is used instead of grapheneOS.

Stock Android does not have the extra memory hardening GrapheneOS has, and does not have zero-on-free functionality, so might be easier to hack than GrapheneOS, especially if owner profile is unlocked. But otherwise, yes.

Nobody123 The only change grapheneOS made to private space was that it allowed for private space to remain secure even after the first unlock via an optional setting, while for stock Android a device restart would be needed.

True.

Nobody123 Is my understanding accurate?

Yes.

GrapheneOS

This Private Space behavior is the officially intended way for it to work and is why you can use biometrics to unlock a Private Space. If a locked Private Space was put at rest, you could not use biometrics to unlock it. The toggle added by GrapheneOS for putting it at rest when locked is a user-facing behavior change reducing usability to improve security. It is not a bug or design flaw that it doesn't work that way by default. It is a design choice to offer what many users want to have. We couldn't simply take away the ability to unlock it with biometrics after first unlock.

Nobody123

GrapheneOS thanks for the quick reply and apologies for opening an old thread. My previous post was not asking about the security flaw that occurs after re-locking private space. I was asking whether stock Android uses a separate encryption key for private space when the private space lock is the same as the device screen lock, or whether this is a feature specific to grapheneOS.

Here is my current understanding based on what was said in this thread: Provided private space has not been unlocked since the last device reboot, it will be as difficult to unlock private space as it would be to unlock the device itself if the device were in BFU state. This holds even if: (1) the private space lock is the same as the device screen lock; (2) the device is stolen while the main space is unlocked; and (3) stock Android is used instead of grapheneOS. The only change grapheneOS made to private space was that it allowed for private space to remain secure even after the first unlock via an optional setting, while for stock Android a device restart would be needed.

Is my understanding accurate?

Nobody123

Stock Android does not have the extra memory hardening GrapheneOS has, and does not have zero-on-free functionality, so might be easier to hack than GrapheneOS, especially if owner profile is unlocked.

But based on your other comments, it seems like these issues only apply if the same passcode for the device is used for private space, the device passcode is cached in memory (which is not supposed to happen in AOSP) and can be extracted. It sounds then that when the same passcode is used for device and private space, it could be possible to break into private space with device already unlocked. However, it also sounds like this would still be unlikely and very difficult even for stock Android, and grapheneOS would make it even harder.

On the other hand, if different passcodes were used (and private space was not unlocked since first reboot), then there should be no way for the private space passkey to be in memory. In this case, difficulty ot breaking into private space sounds to be as hard as breaking into the device while BFU for stock Android, and by extension would also be as difficult for grapheneOS.

ryrona

Nobody123 But based on your other comments, it seems like these issues only apply if the same passcode for the device is used for private space, the device passcode is cached in memory (which is not supposed to happen in AOSP) and can be extracted.

True.

Nobody123 It sounds then that when the same passcode is used for device and private space, it could be possible to break into private space with device already unlocked. However, it also sounds like this would still be unlikely and very difficult even for stock Android, and grapheneOS would make it even harder.

Yes. I never heard of such attacks happening in practice in any system, but it is a well-known theoretical risk one wants to mitigate.

Nobody123 On the other hand, if different passcodes were used (and private space was not unlocked since first reboot), then there should be no way for the private space passkey to be in memory. In this case, difficulty ot breaking into private space sounds to be as hard as breaking into the device while BFU for stock Android, and by extension would also be as difficult for grapheneOS.

True.