T
@dobey said in Encryption and vpn:
Really, there can be no safeguards, because currently we cannot re-lock the bootloader, and even if we had full disk encryption, the key has to be stored on the same flash as the encrypted data. Given that, one could simply copy all data off, and then brute force the wrapped passphrase for the encryption key, to eventually decrypt. Until we can re-lock the bootloader and have recovery without adb, and ideally store the encryption key in the SoC's internal secure key storage rather than on flash, what we can do in UT in terms of physical security is fairly limited.
This probably isn't the best thread for an in-depth discussion of encryption, but your ideas are interesting, so I'll reply here anyway.
You propose a very strong solution, beyond what's employed in most Linux distributions (pseudo FDE in which at least the bootloader - and more often the entire boot partition - is left unencrypted). The security hardware in modern smartphones is, as you indicate, very sophisticated (ironic, given their typical role as privacy destroying, data vacuuming spyware devices), and it would be great for the OS to be able to take advantage of that sophisticated hardware. Given the prerequisites of being able to lock the bootloader and rewriting the recovery however, that seems only possible in a distant future.
In the meantime, assuming a device is switched off, is not a long passphrase for the key a decent start as a safeguard? Imperfect and limited, true, but it raises the bar quite a lot for the attacker, though all means remain vulnerable to XKCD's drug/wrench or San Francisco's lock-up-until-cough-up methods.
Regarding devices which are turned on when attacked, there are apps for Android which will shut off and/or wipe a device after N number of bad unlock attempts. On a SuSE box, I could script something to do this, but I'm not familiar with Ubuntu or Debian logon and screen-unlock security. (Something on my already long list of things to learn someday.) A running device not subjected to logon attempts would still be vulnerable to cryogenic attacks on the RAM, but again, that's a much higher bar than nothing at all.
Considering how Ubuntu Touch is installed, how updates are deployed, and the need of existing devices to piggyback on lower-level guts, FDE is a much tougher nut to crack than simply encrypting those filesystems which can be mounted or remounted after boot. (You know this, I know, - and much more too - but I mention it for those who haven't given the matter much thought.)
For these reasons - and likely others of which I remain ignorant - I don't expect to see FDE in Ubuntu Touch anytime soon. A supported way to encrypt /home or /home/phablet would be nice, but given the more immediate issues facing the developers, I don't plan to open a feature request. I'm happy with chrisc's workaround for a first step.
