I was thinking about this in the morning: How do you prevent the extraction of information from your device if an adversary steals your phone and put it in a farraday bag or something like to block all network communication to extract information from the device later on? Similar to the police for example.
I thought about using a cron-job every x minutes to just reboot the device if a specific service which is always reachable, is not available anymore due to no network access. The reboot would trigger the full disk encryption which would be sometimes sufficient, but is there some way to not just reboot the device but to wipe (to some degree, because the OS is still running) it?
I use this script https://pastebin.com/RyauAyzP for a machine that was having network card issues. It pings google and if it fails, waits 5 min and tries again. After 3 failures, it logs it and reboots the machine.
I think you could use that but then have it also delete the encryption keys so the data would be essentially worthless.
A few problems though. With a device that has hardware kill switches and ‘airplane’ mode type functions, I’d be worried about accidentally wiping all my data because I was out of signal range.
You do have me thinking though, you could use the same function for a “remote wipe” by having it check for the presence of a file on a remote server. If present, wipe the system…
In linux You can use shred in conjunction with find
find $HOME/ type -f -exec shred -n 3 -u {} \;
Warning! The above command is irreversible. You need to be sure what you are doing. This will search all files in your system, then suffle all files content and finally delete it.
It was announced last March that a goal of the Librem 5 was full-disk encryption like the laptops (including with Heads + TPM), granted everything works out with Werner Koch. Wouldn’t that make your scenario moot?
The only attack scenarios I can envision:
Booted phone (locked with lock screen) stolen
Unbooted / rebooted phone stolen
Booted and unlocked phone stolen
In the first scenario, you are relying on your lock screen protections and cold boot attacks (disk decryption key still in memory). This will be highly difficult for an average attacker to bypass.
The second scenario should be nearly impossible for any attacker.
The third scenario means you’re SOL, but hopefully you can manage the device remotely to do some incident response actions (e.g. wipe, track).
It’s typically the first one, but probably I opt for usbkill.
The average attacker have to use the usb-port to extract or even to try to extract information, so I think it would be much easier to trigger a reboot (usbkill even has the option to purge some files before the reboot!) and make it much harder to do anything with the data on the device.
EDIT: It seems usbkill isn’t maintained anymore, so this could be a successor. Still have to test this one, but it seems much more powerful.
I think one should only use ‘shred’ and similar utilities on magnetic drives with file systems that keep data in place. SSDs and USB storage have writing limits. With wear-leveling, the old data might remain anyway as the file location may not be overwritten. It may move.
It does not appear that ‘trimming’ is enabled on my Librem. If I could be more certain of data integrity, I would like to have that function for my SSD even though the drive is encrypted.
This is a great point. Even if you set the phone to remote wipe the SSD, it may not actually wipe the data (due to the wear leveling feature of SSDs) as it would on an HDD.
A solution I can think about would be to discard the encryption keys and reboot the phone to make the data inaccessible.
I’ve proposed an enhancement of killer (the python app I’ve linked above) to discard the keyslots of the fde.
