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.
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.
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.
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.
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
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!
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.
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.
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.
I just discovered your script @Hologram and wanted to say thanks for creating it!
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.
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.
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:
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.