Harald
https://grapheneos.org/faq#encryption
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.
Thank you, but I'm unsure what conclusion to make from this. Is it just the UI enforcing the requirement to unlock Owner first by disabling the user-switching BFU?
As an example. If there was another exploit similar to the SIM-swap lockscreen bypass, could it be used to attempt unlocking a secondary profile by bypassing Owner's lockscreen without Owner' password?
Or is Owner's decryption key necessary in order to unlock the secondary profile?
This makes me believe it's not just a UI security feature.
Harald When the user reboots the device, is there any way for an adversary to extract data from a secondary profile without first unlocking Owner?
There was a lively discussion about this somewhat recently that might be useful: https://discuss.grapheneos.org/d/12848-claims-made-by-forensics-companies-their-capabilities-and-how-grapheneos-fares/47
Harald To access a secondary profile, the owner profile password must be entered at least once. Once that happens, access to others profiles becomes available from the lock screen without logging back in as the owner. Once the owner profile has been unlocked once, it is not needed again to switch to another profile.
That said, data in the secondary profile is still in the Before First Unlock (BFU) state until you enter the profile password for the first time after reboot. Each profile is protected by it's own encryption key that's different from the owner profile. No one would be able to access that profile without knowing your password (or compromising your phone through some not-yet-known exploit).
It still would be best to use strong passwords on all user profiles in case there ever was a way to bypass the owner profile.
Exhort14 To access a secondary profile, the owner profile password must be entered at least once.
This is true under certain assumptions (for example, that the device is not disassembled).
GrapheneLover It still would be best to use strong passwords on all user profiles in case there ever was a way to bypass the owner profile.
Or in case Google changes how unlocking works in support of a parent/child system.
Harald Personally I would assume that a nation-state adversary can disassemble the device and dig through the flash itself.
This was discussed in the previous thread (https://discuss.grapheneos.org/d/12848-claims-made-by-forensics-companies-their-capabilities-and-how-grapheneos-fares/47).
Dumdum That's not related to this topic. It explains why Owner has to be unlocked before secondary users right now, which will likely go away as a requirement in the future. They're going to want to allow secondary users to log in before Owner on tablets, laptops, etc. for them to be properly usable by multiple actual users. The intention of the feature is to work that way, it just isn't the reality of the feature yet.
Harald The Owner lock method is not intended to protect secondary users, and the current need to unlock Owner first is a technical limitation that's likely going to eventually go away. It's one of many things they need to do in order to make secondary users work better.
paul_le_roux Nothing there states that the Owner lock method is intended to protect secondary users.
Harald Instead of saying nation state adversary, be explicit about whether you're talking about them getting privileged code execution in the OS. They can't even access the device encrypted data without exploiting the device.
Owner lock method is not intended to be a boot passphrase and the current situation where it partially acts that way due to technical limitations is not a security feature and is likely not going to work that way in a few years. It's a technical limitation imposed by having sensitive OS data that's not split up by user but which is needed to run any user. They had to put it somewhere, so they put it in Owner. If there was a boot passphrase, this wouldn't make sense, but their design doesn't have one because it hurts usability and accessibility too much.
GrapheneOS I appreciate the reply! This was a straightforward answer to my question.
To be more specific, the threat model is: the user spends a lot of his time in an area with extensive video surveillance such as a university campus. Any time the user's finger is wet, dusty, or whatever else, the fingerprint reader fails and he must enter the PIN (several times per day, in my experience). Even with the PIN scrambling feature and a privacy screen, he needs to enter the PIN so frequently that it can be expected to sometimes be at just the right angle to be visible to a camera. The adversary has access to the surveillance system and records the user's PIN. The contents of the screen (other than the PIN) are not considered sensitive, since the user anticipates he is being recorded.
Possible mitigation 1: the user will keep sensitive data in another profile. However, in my experiment with this, I found there was so much overlap in my use that I was constantly accessing the secondary profile anyway, and we are back to square 1.
Possible mitigation 2: there is a boot passphrase which only needs to be entered upon reboot. The user reboots the phone and it is now protected by this boot passphrase, which he never had any need to enter in his daily use and is therefore not recorded by the surveillance system. However, this is not supported.
Possible mitigation 3: A different setting for the upcoming 2-factor authentication, where the fingerprint/PIN is set to either/or instead of requiring both, with some way to trigger requiring the longer passphrase (which would achieve a similar outcome to 2).
Or, your suggestions?
Harald Possible mitigation 2: there is a boot passphrase which only needs to be entered upon reboot. The user reboots the phone and it is now protected by this boot passphrase, which he never had any need to enter in his daily use and is therefore not recorded by the surveillance system.
I'm not completely clear on how this helps. When would the user reboot the phone, given that entering the boot passphrase in the presence of cameras would disclose it? If rebooting would require the user to leave campus before it would be possible to access the device at all, even to receive calls, it would seem that rebooting would be something to avoid.
I think I've read that some hardware security keys, such as Yubikeys, can simulate a USB keyboard and can be programmed to "type in" a password when activated. Might there be a way to leverage something like that?
Is it possible to shield the keypad area with one hand while entering a PIN or passphrase with the other hand?
I'm not completely clear on how this helps. When would the user reboot the phone, given that entering the boot passphrase in the presence of cameras would disclose it? If rebooting would require the user to leave campus before it would be possible to access the device at all
Yes, that would be the intention. If the user feels he requires the security of the boot passphrase, he reboots the phone and must leave campus to unlock it. This is an acceptable security/convenience trade-off.
I think I've read that some hardware security keys, such as Yubikeys, can simulate a USB keyboard and can be programmed to "type in" a password when activated. Might there be a way to leverage something like that?
I have no idea how or if this would work with the lockscreen.
Is it possible to shield the keypad area with one hand while entering a PIN or passphrase with the other hand?
Possible, maybe. Would I feel comfortable relying on this form of security by obscurity, not really. I am searching for a solution that works even with a presumption of visual surveillance.
de0u Is it possible to shield the keypad area with one hand while entering a PIN or passphrase with the other hand?
Harald Possible, maybe. Would I feel comfortable relying on this form of security by obscurity, not really.
I think among security people keeping a private key private is the opposite of "security by obscurity", which generally means trying to keep the encryption algorithm (or some other mechanism/algorithm) secret, see for example this Wikipedia page.
Harald I am searching for a solution that works even with a presumption of visual surveillance.
Biometrics have various issues -- for one thing, in many jurisdictions one can be forced to "perform" (place a finger on a fingerprint sensor, etc.), perhaps even while unconscious. Voice recognition would probably fall in that category.
If biometrics are ruled out for security reasons, or due to issues with recognition false negatives, and one assumes an adversary can completely observe all screen/keyboard input, it's not clear which options are left. The notion of boot passwords has come up before, and my memory is that developer response so far has been negative.
I guess if you are capable of performing a complicated multi-parameter function mentally, the device could prompt with a random value of one input parameter and you could compute and enter the result. Or it would be possible to use an old-fashioned paper one-time password system such as OPIE or OTPW.
Overall, covering the screen while entering the passphrase might be the most deployable option. Programming a hardware token to "type" a strong password via USB would also likely be deployable, though it would mean mere possession of the key would unlock the system.
I think among security people keeping a private key private is the opposite of "security by obscurity", which generally means trying to keep the encryption algorithm (or some other mechanism/algorithm) secret, see for example this Wikipedia page.
Okay, perhaps my first understanding of this term was mistaken. Nevertheless, I lack confidence that obscuring my PIN is sufficient. I need to enter it too frequently and around too many people or cameras to guarantee that it will never be seen by anyone. I can guarantee this for a passphrase that only needs to be entered once per day.
Biometrics have various issues -- for one thing, in many jurisdictions one can be forced to "perform" (place a finger on a fingerprint sensor, etc.), perhaps even while unconscious. Voice recognition would probably fall in that category.
Any competent user should disable the fingerprint when in a situation of uncertainty. I would like to see a process similar to iOS' "hold the power button to disable fingerprint" which he can do in the pocket, without even seeing the screen!
If biometrics are ruled out for security reasons, or due to issues with recognition false negatives, and one assumes an adversary can completely observe all screen/keyboard input, it's not clear which options are left. The notion of boot passwords has come up before, and my memory is that developer response so far has been negative.
Indeed, the entire problem for me is caused by the high rate of false negatives on the fingerprint reader. I am effectively looking for a way to substitute a PIN for the fingerprint as the secondary authentication. NOT disabling the fingerprint and having a PIN as the primary authentication. I mean having an option to authenticate with a PIN anywhere the fingerprint would be used AFU, while a different passphrase is still the primary authentication mechanism BFU.
Consider modifying the upcoming 2-factor system in this manner: presently it will require a primary passphrase BFU. Then AFU it requires PIN and fingerprint, or falls back to the primary passphrase. Modify it so (at user's option) the PIN/fingerprint becomes an either/or requirement instead of both.
I guess if you are capable of performing a complicated multi-parameter function mentally, the device could prompt with a random value of one input parameter and you could compute and enter the result.
This would also be a great idea that I would find acceptable. However, I am unsure if this is a feature available in the Android system.
