Librem 5 LUKS Status

[joao.azevedo]

@Torrone

Some progress on this topic:

Yes there has been some progress in this area.

@mholiv

Wiki/Docs: https://wiki.postmarketos.org/wiki/Osk-sdl

As part of the work to get Full Disk Encryption Osk-sdl has already been packaged for the Librem 5:

https://source.puri.sm/Librem5-apps/osk-sdl

But this is only a small step, our ultimate goal is not to just provide a live image that the user installs and it has LUKS support.

But a OEM like experience with the OS, in which the user receives a device with the operating system installed already using Full Disk Encryption but no user created.
And all that the user has to do is to run the first setup, create the user and replace the LUKS passphrase via the GNOME Initial Setup dialogs and he is good to go.

Packaging Osk-sdl is one step in this direction, but to accomplish this second option, more work is required.

[Cc281080]

@joao.azevedo

But a OEM like experience with the OS, in which the user receives a device with the operating system installed already using Full Disk Encryption but no user created.

Isn’t this less secure?

All Users would have the same key or how it’s called. Just with different passphrase.
Or key could have been extracted during setup before delivery to the customer.

[epinez]

Shouldn’t be an issue. No problem with randomizing keys/forcing the user to change the passphrase.

[Gavaudan]

The very next sentence after your quote says the user will have to replace the LUKS password.

[Cc281080]

My question is just about the key. Not the passphrase.

To my knowledge the key is needed to decrypt the partition. The passphrase is just used to encrypt the key. And so the passphrase can be easily changes, without adaption of the whole disc.

E.g. if you know the key you don’t need the current passphrase.

[Kyle_Rankin]

@Cc281080

My question is just about the key.

Yes, a challenging part (and a part we are working on now) is incorporating an encrypted image in such a way that each user has a unique key and not just a unique passphrase. There are a few different ways to do it, but it looks like the easiest way might be to just replace the master key and re-encrypt, which LUKS provides tools to accomplish. Another approach would be to script the process of creating a unique LUKS volume for each phone and copy files over instead of imaging and then modifying the default image.

Anyway, suffice to say it’s something we are aware of and are working on.

[Cc281080]

As Byzantium for Librem5 is coming closer:
Is there an update regarding LUKS with an individual key?

May be also with support for the Smartcard?

[beltrandroid]

i think Byzantium will ship with luks by default at some point. Meanwhile I wrote this tutorial into how to manually enable and use luks encryption. its not an ideal method yet, but good enough to test. it also shows with confidence that sooner than later it will work natively

Tutorial: Full disk encryption on Librem5

This post aims to be a simple and noob-friendly tutorial to -test- Luks encryption on the Librem5. This is how I found my way through it and there might be different methods. At the end of the instructions you will have an encrypted root filesystem, encrypted with a pasphrase of your choice, using the full size of the phone’s disk. The original image of Byzantium-luks from Purism is only 3.7GB, but we will expand it to the whole disk. This method doesn’t offer the opportunity to regenerate the …

[Cc281080]

But there is still the issue left that its not using unique keys, correct?

And no smartcard support for decrypting instead of the password.

[beltrandroid]

thats correct, hence the “not ideal” method.
at the bottom of the tutorial i hint at two possible methods to generate our own keys, like using the jumpdrive, would be great if someone takes it forward from there. otherwise hoping byzantium will bring native luks very soon!

[Hologram]

I also wanted the smartcard feature and found a way to unlock Luks with a smartcard on the PinePhone with Mobian. Although this is not PureOS, both are Debian distros and in general it should work with the Librem 5 too. I’ve modified the script from Purism to automate the configuration. Fell free to have a look at https://github.com/sam-m7/smartcard-luks-osk.

As I’ve only tested it on the PinePhone (don’t have my Librem 5 yet) and you might need to add other kernel modules to the initramfs on a Librem 5 I wouldn’t recommend to just execute it, if you’re not feeling ok with reinstalling the OS and loosing all the data stored on the phone.

[Cc281080]

I just reencrypted my LUKS partition and posted the steps in the Tutorial post

Tutorial: Full disk encryption on Librem5

This post aims to be a simple and noob-friendly tutorial to -test- Luks encryption on the Librem5. This is how I found my way through it and there might be different methods. At the end of the instructions you will have an encrypted root filesystem, encrypted with a pasphrase of your choice, using the full size of the phone’s disk. The original image of Byzantium-luks from Purism is only 3.7GB, but we will expand it to the whole disk. This method doesn’t offer the opportunity to regenerate the …

[Cc281080]

I would assume that the following needs to be integrated in the initramfs for your smartcard-luks-osk script in one way or another:

scripts/smartcard_setup.sh · purism · Angus Ainslie / ttxs-firmware

Thats a part from here:

OpenPGP in Your Pocket – Purism

[Hologram]

If you want to use the smartcard reader of the phone then yes. We might need some other kernel module if we want to use a Librem/Nitro Key or some other OpenGPG USB smartcard connected to the USB-C Port.

[Cc281080]

I just tested your script on my L5 with my external SmartCardReader

I had to hardcode ROOT_LUKS = ‘crypt_root’
Then the script run fine when I executed it as root.

I connected my external SmartCardReader already before pressing the power button and I could unlock it. Also when I inserted it some seconds after pressing the power button.
If I enter the wrong key for my smartcard reader the decryption fails and I have to restart my Librem5.

If I just wait without the smartcard reader and enter the wrong LUKS password, I have to wait 90 seconds for my next try.
If I then enter the correct LUKS password it decrypts successful.

Optimization points would be:
1.) ROOT_LUKS should be ‘crypt_root’ for Librem5

Others would just improve the user experience
2.) When it waits for the smartcard it would be good if some hint is displayed.
3.) If the smartcard operation fails, the user should get the option to try it once more.
4.) If no smartcard reader was inserted and the user enters the wrong password, it should get another chance without waiting for a new timeout.

My integrated smartcard reader is not probably working, so I could not test it with it.

[Cc281080]

Hi,

@Hologram
A patch to see a message when it is waiting for the smartcard during boot.
It is for the https://github.com/sam-m7/smartcard-luks-osk/blob/master/files/decrypt_gnupg-sc-osk

--- decrypt_gnupg-sc-osk.orig	2021-10-17 17:58:47.125919486 +0200
+++ decrypt_gnupg-sc-osk	2021-10-17 18:01:42.690929892 +0200
@@ -27,7 +27,6 @@
 
 
 export SDL_VIDEODRIVER=kmsdrm
-plymouth hide-splash 2>/dev/null
 
 if [ -d "/cryptroot/gnupghome" ]; then
     export GNUPGHOME="/cryptroot/gnupghome"
@@ -61,15 +60,18 @@
     exit 1
 fi
 
+plymouth message --text "Insert your smartcard..." 2>/dev/null
 sc_available=0
 time_count=0
 while [ $sc_available -ne 1 ]; do
     if run_gpg --batch --quiet --no-tty --card-status >/dev/null
     then
 	sc_available=1
+ 	plymouth hide-splash 2>/dev/null
     else
 	if [ $time_count -gt 90 ]
 	then
+	    plymouth hide-splash 2>/dev/null
 	    echo "Using fallback and just forwarding keyboard output..." >&2
 	    exec /usr/bin/osk-sdl -v -k -d "${CRYPTTAB_SOURCE}" -n "${CRYPTTAB_NAME}" -c /etc/osk.conf
 	    plymouth show-splash 2>/dev/null

I successfully tested it on my Librem 5 (Byzantium) with my external smartcard reader.

Kind regards,
Christoph

[Kyle_Rankin]

I just discovered your script @Hologram and wanted to say thanks for creating it!

@Cc281080

I had to hardcode ROOT_LUKS = ‘crypt_root’
Then the script run fine when I executed it as root.

This is because fstab on the L5 PureOS shows the UUID for the root device instead of the /dev/mapper file. I made the following modification to the above script to account for that:

$ diff smartcard-luks-osk smartcard-luks-osk.bak 
29,34d28
< case $ROOT_LUKS in
< UUID=*)
<   UUID=`echo $ROOT_LUKS | cut -f2 -d '='`
<   ROOT_LUKS=`blkid -U $UUID | sed 's/\/dev\/mapper\///'`
<   ;;
< esac

So that this section in that script ultimately looks like this:

# Discover the root LUKS device
ROOT_LUKS=`grep -v '^#' /etc/fstab | col | egrep '[[:space:]]+\/[[:space:]]+' | cut -f1 -d ' '| sed 's/\/dev\/mapper\///'`
case $ROOT_LUKS in
UUID=*)
  UUID=`echo $ROOT_LUKS | cut -f2 -d '='`
  ROOT_LUKS=`blkid -U $UUID | sed 's/\/dev\/mapper\///'`
  ;;
esac
crypttab_find_entry $ROOT_LUKS
ROOT_DEV=$CRYPTTAB_SOURCE

However in my case I’m using the internal Librem 5 smartcard reader. When I tried it, I get a flash of the splash screen, then black, then after 90s timeout I get the normal keyboard prompt. I suspect in my case my internal smart card hardware is not being detected but that’s just a guess right now. I just started testing this today.

[Hologram]

Thanks for the feedback @Cc281080 and @Kyle_Rankin. I might find time the next few days/weeks to test the script again and add the changes. I’ve also had the issue with the UUID instead of /dev/mapper using the original script from Purism (https://source.puri.sm/pureos/packages/smartcard-key-luks/-/blob/master/smartcard-key-luks) on my PC/Librem 14 a few months ago. I think it should be changed there too as this can happen on new Debian/PureOS installations.

[Kyle_Rankin]

@Hologram

I think it should be changed there too as this can happen on new Debian/PureOS installations.

It’s a good point. I’ll try to do that later today.

[Kyle_Rankin]

I changed my upstream script but I was also able to get smart card support working! I tried to assemble the necessary changes into this pull request:

Add support for Librem 5 internal SC reader

I know that since you don’t have a Librem 5 you can’t test this, but hopefully we can get some folks in the forum to try this out and then if it works we can decide on the best way to roll this in. At the moment I’m thinking the best way might be to incorporate all of this into my original script so that it can handle both desktop and mobile use cases.