One method to encrypt /home/phablet

[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. :grinning_squinting_face: )
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).

[Dave]

BTW it appears that the latest UBports 24.04 version does now natively support encryption using ext4 (?) fscrypt, using the lock-screen passphrase:

https://gitlab.com/ubports/development/core/ubuntu-touch-session/-/issues/22#note_2475632676

I haven't tried this out yet, but I'm looking forward to.