JayJay That's why I'd like to have an option to exclude selected user profiles from resetting the auto-reboot counter when logged in. Let's say there is an empty profile used to place calls and no other data, but logging into it wouldn't stop the auto-reboot.
What information can forensic tools recover from an "AFU" GOS phone?
dc32f0cfe84def651e0e could you just set a pin for that profile? Even a simple one would prevent the above
Protonuser No PIN will help since I would need to place calls and use basic smartphone features in hostile environment, possibly when detained.
It means the contents of RAM is being flushed during reboot. The contents of RAM include the decryption keys necessary to keep your device unlocked.
[deleted]
final Someone told me data is always encrypted even in AFU and is only decrypted for usage in RAM. How true is that?
4 days later
[deleted] Data on storage is always encrypted. That's how disk encryption works.
JayJay No, since GrapheneOS has automatic reboot while locked enabled by default with a default timer of 18 hours after the last successful unlock. Exploiting the OS only provides access to data in profiles if those profiles have been logged in since the phone was rebooted.
Kerfluffle GrapheneOS has zeroing of freed memory so a regular clean reboot will end up clearing nearly all the OS memory in practice. Auto-reboot does a regular clean reboot and gets the data back at rest. This does not work the same way elsewhere where memory zeroing on free isn't implemented. An earlier version of our auto-reboot feature was taken by other operating systems without applying hardening it requires to function properly.
Kerfluffle GrapheneOS provides substantial defenses against exploitation along with attack surface reduction features such as the USB peripheral control feature you mentioned. It also zeroes freed memory, including all the memory of exited processes, etc. which is what happens on a regular clean reboot such as the ones triggered by auto-reboot.
If GrapheneOS does a regular clean reboot, the data is back at rest. That is not the case elsewhere, which people are missing. On other operating systems, a reboot will restore the device back to Before First Unlock state but without clearing the memory used by the previous boot of the OS other than what gets used again in practice. A memory dump would obtain leftover data from a previous boot outside of GrapheneOS. With GrapheneOS, the data gets cleared, but that's not the case almost anywhere else and is commonly overlooked.
We proposed improvements for Pixel firmware which if implemented would result in a much more robust lower level implementation of memory clearing below the layer of the OS. It appears they're going to implement our proposal for booting into fastboot mode but we're unsure if they're going to implement it on regular reboots.
UpStream The combination of memory zeroing and auto-reboot gets data back at rest, leaving a limited amount of time to potentially exploit the device to get the data without a brute force. If they miss that window, which is extremely likely, then they have to brute force a Before First Unlock state device. Due to the secure element, even a random 6 digit PIN is secure against brute force unless the secure element is exploited. If they can exploit the secure element, which is extremely difficult particularly on the Pixel 6 and later, then they can make guesses at the speed supported by the phone rather than quickly being limited to 1 attempt per day. If they extract the hardware bound key from the SoC, then they can brute force faster than the speed the phone is capable of doing. If you want to prevent any chance of brute forcing the lock method regardless of exploits, then you need to use a strong lock method such as 7 diceware words that's secure against brute force without any hardware security features helping it.
- Edited
GrapheneOS GrapheneOS provides substantial defenses against exploitation along with attack surface reduction features such as the USB peripheral control feature you mentioned.
The USB blocking feature on GrapheneOS is similar to "USB Guard" which is for Linux, and blocks connections from unknown USB devices. There's also something called "USB Kill", which is similar to USB Gaurd, except that instead of simply blocking the USB connection, it acts a kill-switch, and instantly shuts off the computer.
Would you be willing to consider implementing a "USB Kill-Switch" feature? A phone in an AFU state could detect an unauthorized USB device, and immediately return itself to a BFU state, making any attack not only useless, but counterproductive.
The attacker presumably wouldn't know about the kill switch in advance, so not knowing to avoid the USB port, the attacker's very own tools could, ironically, be used as a tool for securing the device.
Kerfluffle A phone in an AFU state could detect an unauthorized USB device, and immediately return itself to a BFU state, making any attack not only useless, but counterproductive.
I second this. Even when a legitimate user triggers this by accident, no harm would happen. They will only need to unlock the restarted device again.
- Edited
Kerfluffle Any exploits that would be available would probably only work on phones in an AFU state
Conjecture, and furthermore conceptually proven untrue by past iOS full jailbreaks.
- Edited
dc32f0cfe84def651e0e I second this. Even when a legitimate user triggers this by accident, no harm would happen. They will only need to unlock the restarted device again.
I have USB Kill installed on my computer, and it's easy to configure it to whitelist specific USB devices. If I trigger it accidentally , I simply restart, and any unrecognized USB devices connected during the rebooting process are added to the whitelist automatically.
[deleted]
dc32f0cfe84def651e0e Open a issue on Github please. This is much needed.
[deleted]
Kerfluffle Please open a Github issue. I am sure they would implement this eventually.
[deleted] I've done just now.
final the phone won't update when in someone else's hands. GrapheneOS cannot protect this.
Does this mean upgrades happen in the background only after unlock, or that user are always prompted to accept or refuse some update ? (sorry never experienced any yet)
Phones can't upgrade without an internet connection or without manually sideloading a new update
If I kept the phone off, or disabled the network on it, it cannot upgrade