One method to encrypt /home/phablet

malditobastardo

@chrisc @trainailleur Hey guys, thanks for your help!

Ok so everything is working fine with ssh after each restart etc. I was also experimenting doing it by the phone terminal but when I go that route I only get half of my config working. For example, the contacts are not visible, the changes made with UTweaktool are not present, the keyboard theme etc. Sadly for some reason doing it by the terminal only decrypt half of my config or something like that. I don't know why.
Also I noticed a worse battery perfomance in my Nexus 5. It was 65% 8 hours ago before going to sleep and today in the morning the phone was dead. Other than that. I will try to figure out why decrypting the phone via the terminal is not working for me, if I manage to get that working or by a script/bash alias I will keep with the encryption long term. Let's see.. Thank you again.

One more thing, I am also experiencing the wifi dissapearing sometimes, usually I fix that by restarting once the phone.

edit2: after trying to decrypt with the new commands, it worked well doing it from the phone terminal

trainailleur

Revisiting this a year later, following a fresh install of OTA-12 on a OnePlus One. It still works.

I did have to bind mount /var/cache/apt as per @jezek 's tip here: https://forums.ubports.com/post/20297

I also dispensed with the cd to /tmp when I remembered that nohup is just writing standard output to a file anyway, so there was no reason not to write to /dev/null, obviating the need to write to a filesystem that will survive the lightdm reload:

nohup /etc/init.d/lightdm force-reload > /dev/null

Will test on PinePhone when I get the chance, but unfortunately my BraveHeart device has been gathering dust for a few months. (Too many projects, too little time, even with all this extra quarantine time in my life. )

As always, DON'T do this unless you know what you're doing* and are prepared to accept the risk of a broken system, either now or at the next OTA.

*A good litmus test might be: you understand what all of the commands in this thread are doing and why they were chosen, as that comprehension implies understanding of the potential consequences as well as the limitations.

trainailleur

@trainailleur said in One method to encrypt /home/phablet:

Will test on PinePhone when I get the chance, but unfortunately my BraveHeart device has been gathering dust for a few months. (Too many projects, too little time, even with all this extra quarantine time in my life. )

I finally tested this on the PinePhone (dev channel). It works fine, as expected, though instead of using a file as the encrypted block device, I created a new partition on the sdcard I'm using for testing.

trainailleur

Have gone further on the PinePhone and copied all of the writable data into a new luks-encrypted partition.

I now have a shell script in my home directory as initially booted that will:

check to see if cryptsetup is installed and if not kick off an install script
turn off swap so we don't end up with encryption keys in swap
unlock the encrypted partition
cd to /tmp (because not doing so was tripping me up in the next step)
force umount /userdata using "umount -l"
remount the encrypted partition on it
in sequence force umount each userdata-mounted writeable part of the filesystem using "umount -l" then bind mount it back on the new, encrypted userdata (the bind mounts for your system can be found with findmnt)
turn swap back on using a new swap file in the encrypted partition with the same -1 setting that the original swap had (a larger swap file, in my case)
force-reload lightdm

Is anything aside from updates writen to permanent storage other than to bind mounts on /userdata? I didn't find anything, but there's always the possibility that I missed something.

All of this adds a couple of minutes to getting the phone ready for use, of course, and there may be things I've not yet discovered which will turn out to be broken.

Given how much is not yet working in the PinePhone, I should probably replicate this on an Android-based UBPorts device like the OnePlus One or the Nexus 5 for further testing. I'm thinking it should probably work with a large container in /userdata, skipping the umount of /userdata and mounting the decrypted block file (and the consequent bind mounts) on a file within /userdata, but this isn't testing I plan to pursue for now, as other tests take priority.

I am not posting my script here because it only applies to how I have set up my PinePhone. There are a few choices I made which would break completely for someone who made different setup choices. Anyone capable of getting this working on their device will need to understand what is meant by each step above so should be able to develop a process that works for them. If anyone who does want to try this and does know what they're doing hits a snag and has a question, I'll try to answer it.

Standard caveat applies: this could break everything on your phone, and UBPorts developers will not support this or help you fix it. Proceed at your own risk.

ernest

Seems that lightdm doesn't restart with the latest OTA. Any tips ?

trainailleur

@ernest said in One method to encrypt /home/phablet:

Seems that lightdm doesn't restart with the latest OTA. Any tips ?

Hmm. I've not been testing lately so hadn't noticed. Will see what I can figure out when I next have some time, but that may be a while. What errors or symptoms occur?

ernest

@trainailleur
Lomiri cannot restart thus the screen remains black, while ssh access works fine.

c4pp4

@ernest said in One method to encrypt /home/phablet:

Seems that lightdm doesn't restart with the latest OTA. Any tips ?

Hi, I'm using the following script (tested on OTA-15 and OTA-16 devel):

#!/bin/bash
if ! dpkg-query -l cryptsetup | grep ^ii 1>/dev/null; then
	mount -o remount,rw /
	apt-get update && \
	apt-get -y install cryptsetup
	sync
	mount -o remount,ro /
fi

cryptsetup luksOpen /home/phablet.img phablet
e2fsck /dev/mapper/phablet
mount /dev/mapper/phablet /home/phablet && \
nohup /etc/init.d/lightdm force-reload </dev/null >/dev/null 2>&1 &

run as root: sudo bash <nameofscript>

llzzrrdd

@c4pp4 x1000 thanks!!!

BodoW

@ernest said in One method to encrypt /home/phablet:

@trainailleur
Lomiri cannot restart thus the screen remains black, while ssh access works fine.

I ran into the same problem on my Nexus 5.
The solution is to lock the screen (Power Button) before initiating the force-reload.
For some reason lightdm does not come back when it was shut down while the display was lit. (It took me quite a while and several WTFs to stumble over this. )
Thus my script is as follows:

#!/bin/bash

cryptsetup luksOpen /home/phablet.img phablet
e2fsck /dev/mapper/phablet
mount /dev/mapper/phablet /home/phablet && \

echo "Lock the screen now!"
echo "Restart in"
for ((t=5;t>0;t--))
do
	echo "$t s"
	sleep 1
done

cd /tmp
nohup /etc/init.d/lightdm force-reload </dev/null >/dev/null 2>&1 &

chris_bavaria

This post is deleted!

chris_bavaria

@BodoW

Hello everyone,

I'm encountering a similar issue as @ernest. After successfully encrypting /home/phablet with LUKS, my screen remains black after restarting LightDM, although SSH access continues to work fine. This happens on my Redmi Note 9S Pro running Ubuntu Touch 20.04 OT-5.

The workaround of locking the screen (using the power button) before initiating the force-reload of LightDM doesn't seem to work reliably anymore. I suspect that something has changed in OT-5, causing LightDM not to come back correctly when it's restarted while the display is on.

Has anyone experienced similar issues with OT-5 or knows of a more reliable way to restart LightDM without the screen staying black? Any help or tips would be greatly appreciated!

Thanks in advance!

Dave

@chris_bavaria said in One method to encrypt /home/phablet:

Has anyone experienced similar issues with OT-5 or knows of a more reliable way to restart LightDM without the screen staying black? Any help or tips would be greatly appreciated!

Thanks in advance!

I've always been using an encrypted home setup similar to what you are trying with my Volla 22 on OTA-4. I'm using the below restart sequence after remounting /home.

RUN THE BELOW CODE AT YOUR OWN RISK, AND ONLY IF YOU FULLY UNDERSTAND IT AND KNOW WHAT YOU ARE DOING. YOU MAY e.g. BRICK YOUR PHONE OR LOOSE DATA. ABSOLUTELY NO WARRANTY.

for i in \
    dconf-service \
    media-hub-server \
    history-daemon \
    address-book-service \
    evolution-addressbook-factory \
    evolution-calendar-factory \
    evolution-source-registry \
    gnome-keyring-daemon \
    mpris-proxy \
    mission-control ; do
    su phablet -c "killall $i" || true
done

pid="$(cat /var/run/lightdm.pid)"
sudo kill $pid

edit sept. 17: I think the above script snippet needs to be modified to include media-hub-server in the list of services to restart. Otherwise passing data between applications fails after remounting /home/phablet (and restart of lightdm). E.g. configuring a background image by selecting a photo in the gallery.

It used to be much simpler on 16.04.

That said, I'd really like for ubports to have a better integrated support for encryption.

Also note that nowadays ext4 filesystem natively supports per-directory encryption which may allow a more efficient and better integrated way to encrypt /home. This github project has more details. I'm using Ubuntu's fscrypt package on a Ubuntu laptop to add another layer of encryption between different users.

Dave

Also note that nowadays ext4 filesystem natively supports per-directory encryption which may allow a more efficient and better integrated way to encrypt /home.

replying to myself: this is called filesystem-based encryption. Here is the relevant documentation for the part living inside the Linux kernel.

Appears that Android nowadays also uses this for providing user-data encryption (albeit with a different user-space tooling).

As this allows very fine-grained encryption of specific directories only, it may be easier to integrate with LightDM, i.e. maybe not requiring a full restart of LightDM after unlocking just some of the more privacy-relevant directories.

Both recent LUKS versions and fscrypt userspace can process the disk encryption password via Argon 2. If you choose sufficiently CPU-intensive parameters for Argon 2 (e.g. multi-second execution time, 4 CPU threads, 512 MB of RAM), then even a password with 40 bits of entropy will be very costly to break using a GPU based brute-force atttack.

If one believes the (pretty outdated) claims on the argon2-gpu gitlab page, then the Argon2 settings that I use with LUKS on my Volla22:

	PBKDF:      argon2id
	Time cost:  12
	Memory:     500000
	Threads:    4

only allow for roughly 8 password attempts per seconds when brute-forcing on a NVIDIA Tesla K20X. That's only 2^28 password attempts per year and GPU!?

Note that Argon2 support in LUKS is not available on the older 16.04 version of UBports, you need 20.04 (focal).