DIY: Encrypted Root Filesystem and Swap using Device Mapper

I have been working on a new project using Slackware as the basis. This project enables using encrypted parbreastions using the device-mapper facility. Device-mapper is built into the 2.6.x kernel and adds extensions to thedev tree. It simply adds names to the tree:dev-mapper-{devname}

which can be mounted as normal devices. The device-mapper module, dm-crypt allows for encryption-decryption to be pipelined as a stage in standard IO to the device. It's fast and transparent. This appears to be the canonical link for the device-mapper project:

All parbreastions encrypted... Encrypting your parbreastions is one way to protect your data. Device-mapper allows all disk parbreastions to be encrypted: root, swap, and even other types, too. That means total protection for your system.

Using encryption is becoming more and more important because of the potential for data loss. Many organizations are now mandating encryption, because they have finally realized that non-encrypted disk parbreastions puts their data at risk. In the recent high profile laptop losses, I'm sure they wish they had it to do over- this time they would use encryption, for sure. This project is in the spirit of locking the horse in the barn now, not after he's already out. Here is a website I have setup for this

The current version is 0.0.1.2:

This project is designed to make building an encrypted system easier, but as the breastle of this post suggests, there is a bit of "doing it for yourself." Study the README file before starting. The README file is still at the first draft stage, unfortunately. Any feedback on the code or documentation would be greatly appreciated.

Two factor... One interesting environment which can be setup using my project is to build a system which has a "two factor" startup requirement. The system could be installed such that two factors are necessary to boot the system: the computer itself and a separate boot drive. The boot drive can be a CD or USB flash drive. My project fits within 64M, so almost any small flash drive will work. This two-factor requirement is analogous to the requirements for starting a car. To start a car, normally two things are required: the car and the ignition key. If you have a car, but are missing the key, then it is still possible to "hot wire" the car. My project is similar, except that even when the system is "hot wired," the thief is still faced with the problem of breaking the encryption key.

Limitations... 1. This program helps boot an encrypted system. It doesn't help you to build an encrypted system, per se. Encrypting an existing system can be tricky, and is best accomplished with multiple disks and-or free parbreastions for the target. It's not too hard to take an unencrypted source parbreastion and write it to an encrypted target parbreastion. There are several articles available on the web for help and advice. This wiki may help you get started, too:

2. My project can be encapsulated as a bootable CD or USB drive. The trick is that user input comes from a file on the initrd, etab. If you are using a CD, then you'll probably want to customize the input file before making a boot media. The README has more information. In general, input is not user-interactive.

Integration with my other project: 10.2-live... I did some quick tests with device-mapper using the dm-snaphsot module, (that is, replacing unionfs with device-mapper.) These tests have already shown some promise that my projects (10.2-live, and erf-dm) could merge. I think it would be ideal for a user to have an unencrypted base platform (readonly, say a DVD-R), and a smaller drive (such as, USB flash) for changes. Only the changes would need to be encrypted. Device-mapper may be the best mechanism.

-- Tracker: He's using a Sino-Logic 16, GPL stealth module.