Is there a plan to support encrypted installations of Ubuntu Core?
I have a device which is sometimes in a slightly public location and I’m concerned if it was stolen, someone could just read the entire disk contents. On a traditional installation of Linux on a laptop I can mitigate this by using LUKS full disk encryption. What’s the plan for Core / snaps here?
yes, i’m currently actively working on this (@ondra has a proof of concept already that i’m basing on), but since we do not really have any in-boot-interaction (like plymouth) to obtain the passphrase it will likely be limited to EMMc installs that also have some kind of secure storage device (or hardware fuse) to hold a key … also, such installs will likely not be re-installable (if fuses are used, these are blown for good in hardware when you do the initial install, a re-install would turn such a device into a brick)
Oh, that’s a shame it won’t be general purpose. This seems to imply we’re not looking to make any kind of Ubuntu Core general purpose installer for non embedded systems?
If once Ubuntu Core goes beyond embedded, i’d expect subiquity to be used (and to support LUKS eventually).
Current focus of Ubuntu Core is embedded and IoT though … which means in the majority of cases it is used headless (or digital-signage/kiosk where it isnt), which ties the encryption key/passphrase to some secure HW device.
Do you have db410c? I have working image to test my POC on it
It’s luks encryption for entire writable partition …
FWIW you can make LUKS get its keys off a storage device that you then remove (I used to do this with a small sd card).
Me? No. I was hoping for LUKS on generic x86 images.
yeah nothing on x86 from me. There we will need to use fscrypt unless we add some smartness to grub. I’m afraid
Hey, I was wondering if there were any new on LUKS encryption? In regards to amd64 in particular. @ogra, @ondra, is there still active work being done on this?
hmm, is this project related to packaging cryptsetup? like: https://gitlab.com/cryptsetup/cryptsetup, or in go?
https://github.com/randomvariable/kms-cryptsetup.
@cratliff the implementation we did was for a customer and built around specific features of the hardware (storing a key in HW, builtin encryption features), it is not generic (and this is really hard to do since proper security requires a safe way to store the key) …
i was pondering to add a simple “manually input the key”, but thats really not helpful in IoT or robotics where you want devices to boot non-interactively … it is still on my TODO to upstream the generic parts of the code itself into the ubuntu-core initrd … though you would have to come up with a working way to store the key in your HW in a safe manner.
That’s pretty much what I expected, implementations that aren’t interactive would be HW specific. I was hoping there would be a something like the generic version you mentioned so I might not have to implement much more than the key storage. Do you have an estimate on when that might be upstreamed? Or is there anyway I could help make a generic solution?
@cratliff there is one more complication when it comes to amd64. When you use full disk encryption approach, we would need to teach grub all the tricks, otherwise it cannot see kernel snap to boot from
Another approach here would be to use u-boot on amd64 
or instead of using luks we would need to use fscrypt or something similar.
It’s something I have plan to experiment with, once time will allow.
So hopefully soon, but unfortunately not too soon…
@cratliff sorry I missed your ping on irc, I’m usually available during UK time so feel free to ping me there
Has any progress ever been made on this? It’s sort of difficult to use snaps for commercial applications as someone can just pull out the SD card and steal all of the data. It would be nice if there was some sort of a pathway to encrypting the entire drive, maybe using something like this to store the key:
Heyo, pinging because I’m now interested in this topic as well. What’s the tea? @ogra or @popey did you ever make any progress on this?
as stated above i worked on one individual implementaion for one specific customer where there was a popwr key storage on the board and the customer also used an individual kernel snap that could handle signed uboot FIT images … AFAIK with Ubuntu Core 20 the snapd and foundations teams worked on a more generalized variant that will make enabling it for brand store customers easier and should basically also work by default on UEFI x86 systems.
(note that full disk encryption kind of went hand in hand with secure boot in our setup so i cant really tell if you could use only one or only the other (and i doubt it would make sense security wise))
Gotcha. I don’t suppose you have any further reading on the topic, do you? I found this whitepaper that I intend to read, but most of my surface-level googling has revealed people from 2016 saying its infeasible.
nope, i moved teams since i did that implementation originally and didnt closely follow what was actually implemented in UC20
(but you made this topic bubble up to the top again, so perhaps someone from the snapd or foundations team can chime in)
