Device-mapper is a new infrastructure in the Linux 2.6 kernel that provides a
generic way to create virtual layers of block devices that can do different
things on top of real block devices like striping, concatenation, mirroring,
snapshotting, etc... The device-mapper is used by the LVM2 and EVMS 2.x tools.
dm-crypt is such a
device-mapper target that provides transparent encryption of block devices using
the new Linux 2.6 cryptoapi. The user can basically specify one of the symmetric
ciphers, a key (of any allowed size), an iv generation mode and then he can
create a new block device in /dev. Writes to this device will be encrypted and
reads decrypted. You can mount your filesystem on it as usual. But without the
key you can't access your data.
It does basically the same as cryptoloop only
that it's a much cleaner code and better suits the need of a block device and
has a more flexible configuration interface. The on-disk format is also
compatible. In the future you will be able to specify other iv generation modes
for enhanced security (you'll have to reencrypt your filesystem though).
I've set up a Wiki. It's naked at
the moment, feel free to fill it with some useful informations.
There's a
mailing list at dm-crypt@saout.de. If you
want to subscribe just send an empty mail to dm-crypt-subscribe@saout.de.
Gmane provides a NNTP interface and web
archive for this mailing list.
There is support for dm-crypt in the latest official kernel 2.6.4
which you can find on kernel.org. Please
use the mirrors for
downloads.
There is a HIGHMEM cryptoapi bug in kernels
before 2.6.4-rc2, please upgrade if you were using such a kernel.
The
latest version of the native userspace setup tool is cryptsetup
0.1.
Clemens Fruhwirth is maintaining an enhanced version of cryptsetup with
the LUKS extension that allows you to have an on-disk block of metadata
which is superior to the current mechanism and was my long term plan anyway but
I didn't find the time to implement that yet...
NEW: I've set up a Wiki.
It's naked at the moment, feel free to fill it with some useful
informations.
Installation:
Once you have a Linux 2.6 kernel with
dm-crypt support on your machine, you need to activate device-mapper and
dm-crypt in your kernel.
You can find both config options under Device
Drivers > Multi-device support (RAID and LVM). Both can be compiled
statically or as modules (code which you can insert and remove from the kernel
at runtime).
The config options are also called
CONFIG_BLK_DEV_DM and CONFIG_DM_CRYPT.
You also
need some userspace tools. You need to install the device-mapper package, you
can find the latest version here.
If you have compiled device-mapper as a module you must load it using
modprobe dm-mod, the dm-crypt module should autoload when
used.
You should make sure that you have the /dev/mapper
directory and the /dev/mapper/control device node.
If not, you
should follow the instructions in the INSTALL file found in the device-mapper package. The INTRO
file also explains some device-mapper basics which might be useful.
Setup:
The mapped device can be created through userspace
tools calling the appropriate device-mapper ioctl. Since there are no dedicated
tools yet everything is done through dmsetup.
(note: If you
don't want to know the details you might want to skipt the next paragraphs and
directly go to the description of cryptsetup)
dmsetup is used to create and remove devices, get information
about devices or reload tables (that means changing the mapping while the device
is in use).
The syntax for device creation is: dmsetup create
<name>
<name> is the name of the created
device. It will appear under
/dev/mapper/<name>.dmsetup then expects the
table on stdin (you could also give a file name as third
parameter).
The table is a list of lines with a sector range, target type and
target config. It looks like:<start sector>
<sector count> <target type>
<arguments>
I'm not going into every detail here. A
dm-crypt table looks like:
0 <sector count> crypt <sector
format> <key> <IV offset> <real
device> <sector offset>
des,
aes-cbc-essiv:sha256 or twofish-ecb.cat
/proc/crypto will show you the supported ciphers.So a complete line to setup the device might look like:echo
0 `blockdev --getsize /dev/hda5` crypt aes-plain
0123456789abcdef0123456789abcdef 0 /dev/hda5 0 | dmsetup create
volume1
Note the use of the blockdev command to get
the number of sectors on /dev/hda5.
The created device will be named
/dev/mapper/volume1.
The device can then be mounted (you should not forget to create a filesystem
first). You can remove the device again using dmsetup remove
<name>. If the creation fails see the syslog for kernel
messages. Don't forget to remove the device before trying to recreate it.
Except for the additional parameters dmsetup can be used somewhat like losetup for cryptoloop. You can use hexdump to create the hex key representation and pipe the output from hashalot into it or something. This is what the cryptsetup tool below does.
cryptsetup:
Because
the way using dmsetup directly is too complicated for most people I'm currently
writing a native cryptsetup program to behave like one of the patched losetup's
out there. It's going to support a lot more features in the
future.
NEW: A first version of the native cryptsetup
implementation in C is ready:
cryptsetup
0.1 requires libgcrypt
1.1.x and libdevmapper
I've got a CVS server, if you're interested in
development I can give you write access. The old version is a shell script that
uses dmsetup and hashalot to do the same. I'm using the same syntax. The script
can be found here.
You can put it into /usr/local/sbin or somewhere you like. The old script
requires the tools dmsetup, hashalot,
hexdump, sed, head, awk and
ls. Most of these will most likely come with your
distribution.
The hashalot tool can be found here (not
required with -h plain).
The dmsetup tool can
be found in the device-mapper package here.
Don't forget to call
scripts/devmap_mknod.sh (only once) in the device-mapper package to
create the /dev/mapper/control device node if you don't use devfs
or udev.
Syntax: /usr/local/sbin/cryptsetup [<OPTIONS>] <action> <name> [<device>]
<OPTIONS>:
-c <cipher> (see /proc/crypto)
-h {plain/<hash>} (see hashalot, WARNING: use ripemd160 instead of rmd160)
-y (verifies the passphrase by asking for it twice)
-d <file> (read key from file
e.g. /dev/urandom; useful for swap devices.
If set, the parameters -h and -y will be ignored)
-s <keysize> (in bits) (WARNING: in bytes for cryptsetup.sh)
-b <size> (in sectors)
-o <offset> (in sectors)
-p <skipped> (in sectors)
<action> is one of:
create - create device
remove - remove device
reload - modify active device
resize - resize active device
status - show device status
<name> is the device to create under /dev/mapper/
<device> is the encrypted device
When creating a device the program will ask for the a passphrase. The
passphrase will then be hashed using the hashalot program and be used
as key.
Alternatively a passphrase can be piped through stdin.
The hashing
can be turned off with -h plain.
The defaults are aes with a 256 bit key, hashed
using ripemd160. Since Linux 2.6.10 you can use an alternative IV
scheme to prevent a watermark attack weakness. aes-cbc-essiv:sha256
should do it.
Don't forget: cryptsetup only creates a mapping. If you call cryptsetup again
after a reboot and supply the same passphrase you will be able to mount your
filesystem you created before.
The on-disk layouts used by the current 2.6 cryptoloop are supported by
dm-crypt.
Cryptoloop also uses cryptoapi so the name of the ciphers are the
same. Cryptoloop also supports ECB and CBC mode. Use
<cipher>-ecb and
<cipher>-plain accordingly with dm-crypt. If you
didn't explicitly specify either -ecb or -cbc before you don't need it now, the
default plain IV generation will be used. There will be additional
(incompatible, but more secure) possibilites in the future because the unhashed
sector number as IV is too predictible.
You'll need to figure out how your passphrase was turned into a key to use
for losetup. There are several patches floating around doing things differently.
But usually cryptsetup will provide a working solution to recreate
the same key from your passphrase.
If you want to migrate from 2.4 cryptoloop please take a look at Clemens
Fruhwirth's Cryptoloop
Migration Guide. He describes the differences between 2.4 and 2.6 cryptoapi
(or basically the bugs in 2.4 cryptoapi...). If you need to cut the key size you
can use the -s option instead of playing with
dd.
(BTW: Clemens has a i586 optimized version of the aes
and serpent cipher on his page, about twice as fast as the kernel
implementation.)
Why dm-crypt?
Originally it started as a fun project because I
wanted to play with the new Linux 2.6 internals. I got a lot of great help from
the device-mapper guys at Sistina (now Redhat). Thank you very much!
It
turned out that this implementation worked great and is very clean compared to
the hacked loop device. The device-mapper core provides much better facilities
to stack block devices. dm-crypt uses mempools to assure we never run into
out-of-memory deadlocks when allocating buffers.
Also the device-mapper
configuration interface provides much more flexibility than the losetup ioctl.
And you can create as many devices as you want with any names you want and
combine them with other dm targets. Online device resizing is also possible,
e.g. if you use dm-crypt on top of a logical volume. There might perhaps even be
LVM or EVMS support for device encryption in the future.
But I don't want to use LVM!
You don't need LVM. Device-mapper is
an all-purpose kernel feature, not tied to LVM in any way.
What if I want to encrypt a filesystem and keep it in a file?
You
can use dm-crypt on top of a normal loop device, call losetup and
cryptsetup.
I'm going to add loop support to cryptsetup so it can do this for
you.
I created my filesystem on the encrypted device. How can I keep it across
reboots?
Very simple. Call cryptsetup again and supply the same
passphrase. It only creates a mapping, not a filesystem.
What if I want to change my passphrase?
At the moment you'll need
to reencrypt your device because the passphrase is directly tied to the key.
There are plans to write a tool that stores the master key on disk and
encrypted so it can be unlocked using a passphrase. You can then change your
passphrase on a regular basis.
If you want to reencrypt your filesystem
you'll have to recreate a new one and move your files.
(I've got an
experimantal tool in the works that allows you to reencrypt your block device on
the fly, assuming you don't reboot your machine...)
I've read about security problems.
Yes, the IV schemes currently
supported by dm-crypt are the same as the ones supported by cryptloop. There's
the ECB mode which is a catastrophe (no IV at all) and the "plain" mode, which
is already a lot better. Older cryptoloops used ECB by default, but with
dm-crypt the default is "plain" (which is the unhashes sector number used as
IV).
Since dm-crypt is extensible there will be better possibilities in the
future, but they will be on-disk incompatible with cryptoloop so you'll have to
reencrypt.
Help! I can't figure out how to use my old encrypted data! I was
using...
There are different implementations out there. Some are
non-cryptoapi and/or broken implementations. SuSE uses its own loop-twofish
implementation which makes dangerous assumptions and is broken when changing the
blocksize ("timebomb crypto"). You cannot use this with dm-crypt.
Can I reencrypt my data without copying all the files?
There's an
experimental and unfinished dmconvert
program that can reencrypt the data while the filesystem is mounted. If you can
get it running it should be safe enough to not eat your data, but make sure you
don't interrupt it or crash your system while it is running. Don't blame me if
something goes wrong.
Can I use encrypted swap?
Yes. You can specify a key file
/dev/random and run mkswap afterwards, so the device will be created with a
different key each time and the data is not accessible at all after a
reboot.
Is there a mailing list?
There's a mailing list at dm-crypt@saout.de. If you want to subscribe
just send an empty mail to dm-crypt-subscribe@saout.de.
Gmane provides a NNTP interface and web
archive for this mailing list.
My system hangs for some time in regular intervals when writing to
encrypted disks.
You are probably using Linux 2.6.4. Du to the
introduction of kthread pdflush is running at nice level -10, which means that
the kernels treats dm-crypt writes as a real time task and doesn't allow
scheduling.
Solution: Switch to 2.6.5 or later or renice pdflush
manually.
Can I use the mount command itself to do all the magic
needed?
I've written an experimental patch for this, see my
post in the mailing list archive.
Where can I send my contributions?
Because maintaining a web page
takes time and people keep mailing me a lot of things I could integrate they can
enter it into this nice Wiki.
Feel free to contact me: christophe@saout.de.