I assume you mean LUKS for the / partition, as you could already mount an external LUKS partition on a microSD card like on any PureOS system.
LUKS for / is being worked on and is a priority. Most of the work comes down to solving how to allow the user to enter their PIN/passphrase at boot using the touchscreen before / is mounted. I would consider that “phase one” and for “phase two” I’d like us to be able to use the OpenPGP smart card and its PIN to unlock LUKS like we (optionally) can enable on the Librem laptops.
Two things I wonder though; does the L5 at present have enough overhead to process full disk/partition encryption, in addition to normal use? Rather, will it be a stress to the system and reduce battery life, responsiveness, etc.?
Also, could the Librem Key be used for unlocking? I don’t suppose it couldn’t, but perhaps there’s a path to a nice integration here. I realize the form-factor of the Key might not be ideal to start.
Thanks.
Disk encryption overhead is pretty minimal on modern processors and indeed most smartphones offer it so I wouldn’t worry about LUKS on a Librem 5. WIth respect to the Librem Key being used for unlocking, yes, it would be possible via the same mechanism that we’d use to unlocked with the integrated OpenPGP smart card reader.
Okay, cool.
I’ve never used an OpenPGP smart card before. Searching for them shows me 3.5 x 2" cards, plus others which appear to be the size a SIM card. What’s the form factor I should be looking for?
Thanks.
Yes but why not just have a quick fix.
right now let dev people solve the “touchscreenkeyboardproblem” and just focus on encrypt the / partition on a librem 5 and use a USB C keyboard (since they got usb-c support).
Would not that be a quickfix or do i miss something ?
Can you use LUKS for the / (or do you have to erease it) ?
Because not being able to boot up your phone unless you are carrying an USB-C keyboard around with you is a no-go for most people?
If you are willing to do that, you are probably also already able to manually encrypt and use / with LUKS (with a nice HOWTO), so that should always be possible.
Yes if I have to choose between not having encryption or do having encryption (but i have to have a usbkeyboard around when i boot) I would go for the encryption option.
Its a temporary fix I understand that…But when they solve the problem with touchscreenkeyboard its probaly a software fix and then I can leave my home without a usb-c keyboard.
I agree with you that a mandatory keyboard and the like would not work but LUKS encryption on a linux mobile phone has been solved. I think postmarketOS did the heavy lifting here. I tested their solution and yah! It works.
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.