First let me backtrack a little bit and start with a bit of context
In the linux kernel, device mapper is provided as a way to create virtual block devices
those block devices usually have the names /dev/dm-0, /dev/dm-1 and so on
and udev creates symlinks /dev/mapper/$TARGET where $TARGET is the dm target name
They're used for a whole bunch of purposes amongst which transport encryption of block devices using dmcrypt module
as well as integrity checking both for read-only targets for the whole device as well as per-sector integrity information
They're also used for the Logical Volume Manager (LVM)
and a whole bunch of other things, you can check dmsetup or this directory in the linux kernel source tree
Here is an example of such virtual block device tags
we have 2 disks /dev/sda and /dev/sdb on which /dev/mapper creates pv0 and pv1
which are encrypted devices used together as a physical volume myvg with 4 logical volumes, lv1 to lv4
lv1 is mounted on root (/), lv2 on /var, lv3 on /home, lv4 is swap
One thing that people sometimes forget is that encryption for crypt target is not done by cryptsetup itself but by the kernel crypto API
the source device (sda or sdb) can be either random noise, in which case we have plain dmcrypt device or either have a header with metadata
metadata consists of type of metadata, encryption cypher, the key derivation function (KDF), the UUID...
and that's used for key management.
That's what's cryptsetup does, it reads those headers and performs key management, so the most common header is LUKS...
at least for Linux
these days cryptsetup agreed to perform key management and uses libdevmapper to create the mapped devices
and then delegates all the crypto to the kernel
For a number of type volumes, that is volumes other than swap and /tmp
it's usually a good idea to use LUKS rather than plain dmcrypt device
because that means there is more infrastructure to prevent yourself from shooting yourself in the foot
cryptsetup in Debian is shipped by various packages
I just listed a few here
so we have cryptsetup-bin and libcryptsetup for the upstream bits, respectively for the upstream binaries and the shared libraries
and for those two we also ship udebs for the integration into debian instaler
we also have gazillons of scripts
that are spread across those two packages.
these scripts are used to parse crypttab and turn the cryptab entries into cryptsetup Open commands
with suitable arguments
we also ship scripts to use the output of a program as passphrase
as well as initramfs as boot scripts and hook scripts for unlocking at early boot stage
To this day, our scripts are spread amongst those two packages, since about a month or two
cryptsetup is a transitionnal dummy package that depends on these two
it will remain so for another release cycle to ensure a small upgrade path
One thing that is quite important to mention is that we are upstreams for these bits
so our work is not only about packaging
we also need to do the Q&A, the maintenance, and development of the scripts we are shipping
some debian derivatives are dependable
Since cryptsetup, especially when unlocking at early boot stage is fairly low level, when things break they do quite badly.
that makes people quite angry at us, so we need to be quite careful with the Q&A here.
Here is a timeline of the project with a few selected highlights
In 2004, the linux kernel 2.6.4 was released, being the first to contain the dmcrypt module
Shortly afterwards, dmcrypt landed into Debian
about one year later, upstream released 1.0
just in time for etch, we had the first partman-crypto release
it was possible to setup encrypted volumes in the installer
then skipping 7 years of lot of development
In 2013, upstream released 1.6
LUKS defaut cipher mode switches from CBC to XTS which I think most of you are using today.
Skipping another five years, upstream released 2.0 earlier this year
with a new LUKS2 on-disk format which I may talk about if I have time, and a bunch of experimental features
about 2 months ago, Jonas Meurer and I met for a packaging sprint in order to refactor the whole Debian parts
we moved a lot of code, did some triaging and unfortunately it introduced some regressions
In the future, hopefully before the freeze, upstream will release 2.1 with LUKS format defaulting to LUKS2
Now I will focus on unlocking at early boot stage, because that's what most of our work is about.
We also provide scripts for unlocking at later stages, mostly for manual unlocking and SysV init scripts
For those of us who use SystemD, it comes with its own crypttab and parser logic
so they're not using the cryptsetup binaries at all, but they are using libcryptsetup
To give proper credits, all this is joint work with Jonas Meurer and other contributors
Along the year we have added support for multiple use cases
People wanted to have a custom block device stack and to be able to unlock it
This doesn't come out of the box, so they come with their own workarounds
But they are not always aware of our work
I guess we are bad at advertising, so it's a good reason to talk about this today.
First I have a pleed, that is you should never use our own initramfs script as a baseline for your own scripts
because those are using our internal API and are subject to change without notice.
If you want to use custom initramfs integration, you need to stick to the documented interface, or ask us to extend it
So when we had this sprint we kind of reworked the whole initramfs integration as I said
and that broke a lot of third-party scripts unfortunately
I filed RC bugs against them, the ones I found at least
but it's a bit unfortunate, it's not because it's a shell script that it's free access for copying
One thing I want to talk about is remote unlocking using SSH
Since Lenny, the dropbear SSH server has initramfs integration and today it is in dropbear-initramfs package
You can install dropbear SSH into the initrd of your server, then ssh into that initrd and unlock your device there.
What happens is the initramfs boot scripts are blocking on the password prompt
but you can access to it remotely and ????? passphrase in some ask-pass ?????
then some magic happens and you bypass that password prompt that's on the local console