Why Duress Works This Way?

trashaccount

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.

Carlos-Anso

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.

Murcielago

@de0u @GrapheneOS @final

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

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.

Carlos-Anso

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?

trashaccount

I'm sorry if its not clear what im asking. I can word it better if needed.

trashaccount

Carlos-Anso I don't want it to delete another user at all. It should delete everything.

My goal would be to make the duress process deniable.
If the OS would have full disk encryption where all unique user data is encrypted, the encryption keys could be wiped when the duress pin was entered in a stealthy manner. Then auto reboot would restart the device, instead of that happening automatically after duress pin. After all that it would request the early decryption key as normal on reboot, without any way to tell what happened. There would be no possible combination at that point.

JollyRancher

trashaccount
Duress can't really be made deniable without designing it to be with firmware access.

For duress to be deniable it would either need to load a full replacement profile that would stand up to scrutiny or be selective in what it wipes.

Realistically, a selective wipe would be best. I.e. put in the duress pin and it wipes certain files/folder's.

The issue with that is that apparently it will leave really obvious traces in an unlocked forensic examination.

A phone that is wiped back to factory defaults is always going to be inherently obvious.

Watermelon

GrapheneOS We chose to have it wipe the data and then power off the device.

Out of curiosity, is this poweroff a clean poweroff utilizing the zero-on-free feature, or an instant poweroff? I was having a difficulty understanding whether it's this or that by reading this thread and I wasn't able to find the answer on your website. Also now that you've implemented RAM wiping on boot for normal OS boots just in case zero-on-free isn't enough, would you change duress PIN to reboot instead of powering off? Thanks

trashaccount

Watermelon

is this poweroff a clean poweroff utilizing the zero-on-free feature, or an instant poweroff?

Yes.

GrapheneOS

Watermelon It's a clean shutdown. Clean reboots and shutdowns both zero data via zero-on-free. Zeroing at boot is for after unclean reboots or shutdowns in combination with fastboot mode supporting it since April 2024 on Pixels due to us requesting it in January 2024.

Watermelon

GrapheneOS That's great! I would've never expected a device to be able to do a clean shutdown after all of its storage is wiped while being in use. EDIT: Maybe add it to the explanation on your site? It's good to know the RAM gets wiped as well. It's impressive.

« Previous Page