Hello!
While I am patiently waiting for my Evergreen phone I was wondering if there was any status on LUKS in regards to the Librem 5.
Recently people where able to figure out how to get LUKS working on the arm64 PineBook Pro under Manjaro and under Debian (abit slowly).
The FAQ say that LUKS on the Librem 5 “is in progress” but I am wondering if there are any updates on this?
With the quantity of sensitive data that a phone might posses I think disk encryption is quite impotent.
I’m really interested in this too.
Related topics:
Community diskussion and links / no official post:
Explanation how storage of secrets might work by Kyle and dcz:
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.
Sounds good!
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) ?
Common people lets make this work !
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. 
Ok where to find a howto for this ?
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system
It is not Debian specific, so that might also be valuable to check out, but the arch docs are mostly excellent.
Should be possible to modify this to better fit the L5 partitioning.
The size of the OpenPGP card on the Librem 5 is 2FF, which is the size of a miniSIM.
See: https://spin.atomicobject.com/2014/02/09/gnupg-openpgp-smartcard/
Hey!
Thanks for responding.
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.
Wiki/Docs: https://wiki.postmarketos.org/wiki/Osk-sdl
Blog post: https://postmarketos.org/blog/2017/09/03/100-days-of-postmarketos/#initramfs-is-full-of-new-features
It looks like they use a custom initramfs image that references resources on an unencrypted boot partition.
Thanks for all the great work you do for the community.
Some progress on this topic:
Yes there has been some progress in this area.
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.
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.
Shouldn’t be an issue. No problem with randomizing keys/forcing the user to change the passphrase.
The very next sentence after your quote says the user will have to replace the LUKS password.
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.