Encrypted File Systems

Find a couple of blank floppies on which to test an encrypted file system. Then, create an encrypted file system using DES encryption:

# dd if=/dev/urandom of=/dev/fd0 bs=1k count=1440
# losetup -e des /dev/loop0 /dev/fd0
Pass phrase: des test
# mke2fs /dev/loop0
# losetup -d /dev/loop0

A couple of notes about this example:

Finally, create one more pair of disks which use different passwords. (If you want to be unusually perverse, use your previous IDEA test pass phrase on your second DES test disk and vice versa.)

Now we're ready to mount these disks. First, try to mount the floppies using a standard mount command:

# mount /dev/fd0 /mnt -text2

These commands should fail with “can't find an EXT2 file system.” Now try mounting each floppy again:

# mount /dev/fd0 /mnt -text2,loop,encryption=idea
# mount /dev/fd0 /mnt -text2,loop,encryption=des

This is another area where gremlins have appeared on my system. Once IDEA encryption worked fine but /dev/urandom failed; in another case, /dev/urandom worked but IDEA encryption produced kernel warnings on every even sector.

Now a few more tests. Edit the /etc/fstab file to add these entries:

/dev/fd0 /mnt/des  ext2
        defaults,noauto,loop,encryption=des  0 0
/dev/fd0 /mnt/idea ext2
        defaults,noauto,loop,encryption=idea 0 0

Try to mount your test disks on /mnt/des and /mnt/idea. Once again you should be prompted for a pass phrase and will be successful only when encryption algorithm and pass phrases match.

Finally, reboot your system and repeat these tests. If possible, install the modified kernel on a second system and verify that you can exchange media between the systems. Such is life on the bleeding edge of technology.

Now that we have encrypted file systems, what can we do?

Even taking a cursory glance at the trends of security software, one notices recurring themes. Encrypted file systems protect the data on disks. SSH (Secure Shell) encrypts and authenticates communications. Secure-RPC (remote procedure call) encrypts interprocess communications. RPM authenticates software upgrades.

Is there any question that encryption and authentication routines belong in the kernel? Encryption keys could be stored with each device and process, and with negotiations for unique session keys automatically mediated between any process within and without the system that desired it. There would not be needless duplication of identical routines, or worries about export restrictions since these issues would have already been addressed. If necessary the encryption routines could be localized to a loadable module, although that raises certain security issues.

The downside is anyone with root access can grab the encryption keys from the system tables; however, once root is compromised all bets are off anyway. On the other hand, supplying strong encryption and authentication services in the kernel should reduce the risk of root becoming compromised. Also, DH key negotiation means that my keys aren't compromised even if I'm talking to someone who is compromised.