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 p olume1.
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 p olume1.
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 p olume1.
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 p olume1.
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 p olume1.
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 p olume1.
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 p olume1.
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 p olume1.
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 p olume1.
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 p olume1.
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 p olume1.
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 p olume1.
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 p olume1.
The device can then be m