Encryption and vpn

trainailleur

There is a very manual process for running an encrypted home directory pioneered by @chrisc and detailed here:

This is not a user friendly process, is not supported by the UBPorts developers, and will likely break and need to be manually fixed after any major OTA update, so do not try this unless you know your way around cryptsetup and filesystem mounts very well.

Church

Hi
sorry about the username , it is the name of a superhero in the comic "the boys" recomend a read

So encryption is on hold then. looked at the guide and a bit of my depth there. So basically what is the safeguards in place if say a thief would just copy the phone with adb commands, the rootpassword? just a bit confused when mixing Linux and android for the first time

will have a look at the vpn solution again
thanks for replies

Lakotaubp

@TempUsername No problem feel free to change it as I said.

Church

So tried the vpn guide above , but when I download the ovpn file from azirevpn I don't get a private key. so I tried first with the options certs plus password , didn't work. then password only , didn't work. contacted azire support to see if they can help, will post again if I get it to work

advocatux

@TempUsername see this guide too https://ubports.com/blog/ubports-blog-1/post/vpn-on-ubuntu-touch-178

Church

thanks , but still get "no valid vpn secrets"

advocatux

@TempUsername then probably only Azire can help you, we'll see what they have to tell you

dobey

@Church said in Encryption and vpn:

So encryption is on hold then. looked at the guide and a bit of my depth there. So basically what is the safeguards in place if say a thief would just copy the phone with adb commands, the rootpassword?

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.

trainailleur

@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.

haveaniceday

Hello,

there are good news and new challenges.
My Aquaris M10 FHD now automatically mounts a LUKS volume at /home/phablet when booting, without the use of custom scripts.

I achieved this by creating the LUKS volume (based on your previous posts) in a ~3GB file /userdata/luksHome.img, then adding a file with random bytes /userdata/luksHome.key as cryptographic key.

An entry in /etc/crypttab uses this key to decrypt the volume, when the boot order triggers cryptdisk. The option _netdev is necessary, because otherwise /userdata isn't mounted when LUKS tries to access /userdata/luksHome.img. The original purpose of this option is to wait for network devices to start. noearly serves a similar purpose of skipping the first invokation of cryptdisk. We want the second one, where the other mounts are finished.

# <target name>	<source device>		<key file>	<options>
luksHome	/userdata/luksHome.img	/userdata/luksHome.key	luks,noearly,tries=1,_netdev

So now we have the LUKS as a device in /dev/mapper/luksHome, which we mount at /home/phablet.
Unfortunately, we cannot use /etc/fstab as it is created by dark magic (any info about it is appreciated!)
Therefore we append one line to /lib/init/fstab, which is a normal, non-magic file.
Note the _netdev option, otherwise you softbrick your device.

/dev/mapper/luksHome	/home/phablet	ext4	defaults,_netdev	0	0

Now to the challenges:

Storing an unwrapped keyfile next to the cipher is as useless as no encryption at all. An acceptable solution for now would be using a passphrase, which the user must enter each time the device boots. The missing On Screen Keyboard and the Splash-Screen (which hides the passphrase prompt I assume) are obstacles for now. Maybe one can use a USB keyboard as a compromise?
A second option is the keyscript feature of crypttab. This script is called by cryptdisk and returns the key. For example there is a keyscript which receives the key via UDP [1]. Nice would be a keyscript to unwrap a key file using a hardware token like YubiKey.
Lastly, the biggest challenge: encrypting /home/phablet is not sufficient. There are more writable paths. At first I wondered why my wallpaper changes persisted reboots between encrypted <-> unencrypted mode. App (de)installations have persistent effects regardless is /home/phablet is the original folder or the mounted LUKS device, which should be impossible.
My guess is that the bind mounts [2] from the /etc/fstab are the cause of trouble. They happen before /home/phablet is shadowed by the crypto mount. As a result, a bind like /opt/click.ubuntu.com always leads into the unencrypted folder.
Maybe this can be fixed with mount orders. Or maybe the entire partition which gets mounted at /userdata should be encrypted. This way OTAs might still work afterwards. The very challenge is that we can't use /lib/init/fstab because this file is probably located inside the folders we want to encrypt.

What do you think? Do you know how we can receive a passphrase during boot time via user interaction?

@dobey

then brute force the wrapped passphrase for the encryption key, to eventually decrypt

You can brute force every cryptosystem (well, but the OTP). This is not an argument against using wrapped keys, but rather an argument for educating users about strong passphrases. Until we can use secure enclaves, TPMs, vein scanners or similar is a long, long way for UT. For now we need to just raise the base line to a reasonable minimum.
Our attacker model should not be nation-state, but rather the common MTP-/ADB-savy "finder" of your lost phone.

[1] https://github.com/basak/netkeyscript
[2] http://manpages.ubuntu.com/manpages/xenial/man5/writable-paths.5.html

Have a nice day!

haveaniceday

@trainailleur said in Encryption and vpn:

but I'm not familiar with Ubuntu or Debian logon and screen-unlock security

Maybe those files are what you are looking for:
https://github.com/ubports/unity8/blob/xenial/qml/Components/PinLockscreen.qml
https://github.com/ubports/unity8/blob/xenial/qml/Components/Lockscreen.qml

trainailleur

@haveaniceday said in Encryption and vpn:

What do you think? Do you know how we can receive a passphrase during boot time via user interaction?

PostmarketOS uses OSK-SDL to accept encryption password input on touchscreen devices during startup. If you're good with C++, you might have a look at the code on Gitlab.

I'm still slowly working my way back into coding after many years of only scripting and am sadly not up to the challenge of seeing how that could be integrated to the Ubuntu Touch boot process.

Bear in mind that even if you can unlock a crypt on startup, integrating this into the UBPorts installer is going to be another large challenge.

@haveaniceday said in Encryption and vpn:

Maybe those files are what you are looking for:
https://github.com/ubports/unity8/blob/xenial/qml/Components/PinLockscreen.qml
https://github.com/ubports/unity8/blob/xenial/qml/Components/Lockscreen.qml

Thanks, I'll take a look. Maybe it's not too hard to integrate a counter there and link to a shutdown or nuke script.