Can someone explain why duress prevents the device from booting? ATM duress is not deniable but it could be if it just removed the data encryption key without any further action or notice. Displaying the "wrong PIN" message as usual. If this is even possible of course. Im sure im missing something important here.
Why Duress Works This Way?
trashaccount ATM duress is not deniable but it could be if it just removed the data encryption key without any further action or notice. Displaying the "wrong PIN" message as usual.
On the one hand that would leave the contents of RAM available for potential exfiltration. And on the other hand leaving the system running without access to storage might eventually lead to a spectacular crash -- for example, an incoming call would cause the dialer to look up a contact, at which point the kernel would notice all storage had broken, and panic.
- Edited
would leave the contents of RAM available for potential exfiltration
That's true. But i don't know how they'd go about it when the USB port is disabled. I'd think deniability is more important than wiping ram which will happen anyway due to auto reboot.
system running without access to storage might eventually lead to a spectacular crash -- for example, an incoming call would cause the dialer to look up a contact, at which point the kernel would notice all storage had broken, and panic.
App data could cause a crash if its running but they could just hide errors or force them to shut down/clear data etc.
What i dont understand is why the phone gets corrupted on reboot. In BFU data is not accessible either way. Why cant it boot normally without a possible pin to get it?
de0u Leaving the system running without access to storage might eventually lead to a spectacular crash -- for example, an incoming call would cause the dialer to look up a contact, at which point the kernel would notice all storage had broken, and panic.
trashaccount App data could cause a crash if its running but they could just hide errors or force them to shut down/clear data etc.
The kernel is not designed to work if all storage I/O suddenly fails or returns random bits. The window system is not designed to work if all file I/O returns errors or random bits. Pretty much no software is designed to look like it is OK if all file I/O returns errors or random bits. It would be possible in theory to replace a running system with a pretend lock screen, but not particularly easy.
trashaccount What i dont understand is why the phone gets corrupted on reboot. In BFU data is not accessible either way. Why cant it boot normally without a possible pin to get it?
A normal installation or a deliberate "factory reset" results in a user data partition ready to run the setup program, including, I suspect, a wrapped storage key in the secure element for BFU operation. A credential wipe results in a different situation, one where the user data partition can't be decrypted at all, and is not ready to run the setup program (or anything else). Being unable to mount the user data partition is not normal and the abnormal situation is reported.
de0u Is it being decrypted at all without any password input in BFU?
trashaccount We chose to have it wipe the data and then power off the device. It does that instead of rebooting into recovery to factory reset after wiping. The recovery factory reset process is offered as an option after the OS boots a couple times and fails to decrypt any of the data because of the wiping. It has the same end result as if we did it automatically but without booting into an easily interrupted wiping process. We don't see a reason to make it seem as if the device has to reboot to recovery in order to wipe where an adversary with the phone will see that it's wiping itself and will likely think it's still possible to stop it even though it was finished doing it before it rebooted into recovery. We don't see any good that can come from changing the approach from powering off after wiping to rebooting into recovery for the usual factory reset process. What's the disadvantage of letting people trigger the factory reset from the rescue menu shown when the device can't decrypt any of the data?
de0u Yes, this would leave a ton of sensitive data around in memory, registers, etc. There's no realistic way to get it cleared beyond a clean reboot or shutdown. It's not really clear if a reboot or shutdown is better, but in this case shutdown makes more sense since the device is going to fail to mount data and then get stuck at a rescue screen until someone tells it to factory reset.
trashaccount What i dont understand is why the phone gets corrupted on reboot. In BFU data is not accessible either way. Why cant it boot normally without a possible pin to get it?
Android distributions encrypts all data, but some data is encrypted differently than others. Some of this data is encrypted by your device, and the more sensitive data, such as your files, is encrypted by the user's credential (PIN/password). When you are booting into the OS after a restart or power off, all the data that is Credential Encrypted (CE) is inaccessible, because you need to insert the credential to generate the derived key to decrypt such data.
Obviously, if all data was encrypted, the OS couldn't be used, so a tiny part of the operating system is Device Encrypted (DE) and is decrypted by the device when booted, the rest of the CE Owner profile data is decrypted once the user inserts it's credential. This small part is made accessible at boot so you can insert your credential, see the time, still get alarms, etc.
A good example of this difference is apps: Some data is Device Encrypted, such as the APKs of apps that are installed on all the user profiles, HOWEVER, the data of each app instance within user profiles are Credential Encrypted. BFU-only extractions would tell someone they had a notes app installed, but not any of the notes, saved preferences or other data about the app. You can see with how Owner can see other apps installed exclusively in other user profiles from the Settings app that this is the case. This is also how an app updated on one profile updates on all the others.
Some apps may allow data accessible at a BFU state if an app supports a feature called Direct Boot, but this is an opt-in and apps should not use unless necessary (such as alarm clocks or dialers).
If you still dont understand, check out this Cellebrite keynote about Android encryption types.
Duress PIN erases all data including Device Encrypted data, it is booted into recovery because that DE data's keys have also been purged and therefore it cannot boot into the OS at all. The recovery regenerates a new install of the operating system with new device encryption keys. This is to make sure all device encrypted data is lost.
Worth noting GrapheneoS will be adding a way to use the Owner account lock method as an early boot passphrase for device encrypted data such as saved Wi-Fi networks and installed APKs.
Wiping with duress prevents recovering any of the OS data, whether it's the early boot DE data or CE data in users.
- Edited
final GrapheneOS Thank you. This is very useful information to me. Do you think it would be useful/possible to optionally only erease CE data by duress during runtime to have plausible deniability without any visible changes to the attackers?
It sounds to be possible if GrapheneOS implements the early boot passphrase, because that could work like a LUKS volume without any usable keys for unlocking when duress gets triggered.
trashaccount Do you think it would be useful/possible to optionally only erease CE data by duress during runtime to have plausible deniability without any visible changes to the attackers?
If the keys for credential-encrypted data are lost, then pretty much everything on the device, probably including the kernel, can't continue running and will likely crash (not great for deniability). If the suggestion is to wipe CE keys and reboot, then the system will enter an atypical state -- the best that could be hoped for would be for the setup wizard to start (also not great for deniability).
I think the situation at present is that the GrapheneOS developers believe that a reliable duress wipe with reliable deniability is infeasible. It is possible that there is some way to do it that they haven't thought of... but if that is the case I suspect it would be found by somebody who has read all of the relevant code.
trashaccount That wouldn't provide plausible deniability.
Until the OS shuts down or reboots after wiping what's needed to derive any of the encryption keys again, it can still access all the data. It still has access to all the data it did before wiping other than the stuff directly related to deriving the encryption keys which it doesn't need beyond trying to log in, change the password, etc. Rebooting or shutting down after wiping is a crucial part of it. That gets rid of the current OS access to the data and the data it had in memory. It's possible to implement wiping of specific keys and data in memory but it doesn't really compare to doing a reboot.
Wiping only secondary users without a reboot is possible but wiping secondary users will not be deniable. You would still be better off having a reboot after doing it to get remnants out of memory where it wasn't wiped by our page allocator zeroing and the standard implementation of purging keys from profiles that are put at rest or deleted. It's not strictly necessary but the reboot makes sure that leftover remnants despite having kernel page/slab zeroing, zero-on-free in userspace, etc. don't stay around. Bear in mind a lot of the core system processes handle more than one user including system_server and SystemUI. It's possible to clear everything that's no longer used but that doesn't mean a bunch of traces of what was being done in the secondary user don't linger around. Most will be gone, sure, but a reboot afterwards is best. Would you want to take a chance with this if you were depending on it? Probably not.
- Edited
GrapheneOS First of all, thank you again for the clarification. I understand, the reason why its not deniable is because it reboots after the duress process finishes. However if auto-reboot finishes the job instead of the duress process + early boot required the password with no possible keys, then it could be deniable. Thats my point.
Thank you for the high-quality yet understandable answers here on this topic. I find it very helpful to understand the Duress feature, what works and what doesn't and why.
trashaccount
Theres no deniability as even following deletion of the encryption keys of a secondary user there will still be traces of the previous existence of that user in system logs etc.
Carlos-Anso Even if there would be a hypothetical early boot passphrase like on Linux with FDE? That would prevent them from even viewing the logs etc. And the memory would be cleared from the previous session via autoreboot + they couldn't abuse the USB-C port while the OS is booted anyway.
I'm sorry if its not clear what im asking. I can word it better if needed.
trashaccount if you are depending on an adversary to not be able to gain access to the owner user and accessing logs then why would you need to use duress to delete a secondary user?