OpenBSD Encrypted Virtual Filesystem Mini-HOWTO

Introduction

This Mini-HOWTO covers how to create and use local, encrypted virtual filesystems with OpenBSD (that is, encrypted virtual filesystems on physically attached, local disks as opposed to on remote machines over the network). Although nearly undocumented, OpenBSD makes the creation and use of encrypted virtual filesystems rather easy. Hopefully, this Mini-HOWTO will help document this feature a little better.

Caveat and Disclaimer

As always, if you destroy or otherwise lose your data, it is obviously your fault. Don't blame anyone else, especially me, for whatever undesirable circumstances may result from your actions. You have free will. Deal with it. :-)

The Implementation

Rather than implementing some ungainly means of grafting encryption on top of OpenBSD's existing filesystem semantics, encrypted virtual filesystem support is inserted into OpenBSD's existing vnode(9) system via vnd(4), OpenBSD's Vnode Disk Driver. The only encryption algorithm implemented so far is blowfish(3) and, while it would be nice to have a choice among a few good ciphers, this limitation is not really much of a shortcomming since blowfish is a relativey fast and secure algorithm.

Actual shortcomings are:

Size Limit -- Until OpenBSD 3.0 was patched to exceed it, the maximum usable encrypted virtual filesystem size was about 2.2 GB. Now, although I have not actually verified it myself, I understand that the maximum size is about 8.2 GB, this limit being due to a limitation of mkfs when working through a vnd mounted filesystem.
No HMAC -- No HMAC is kept on the encrypted virtual filesystem. This shortcoming, also shared by Linux's loopback encrypted filesystem, allows data insertion/modification attacks as explained by Jerome Etienne in his paper, Vulnerability in encrypted loop device for Linux. Although the exposure here is limited and it's exploitation is unlikely, it is real. For the truely paranoid, a relatively simple means of adding HMACs is explained below.

Creating and Using

There is only one prerequisite for using virtual encrypted filesystems under OpenBSD. Your kernel must have been compiled with at least one vnd pseudo-device defined. For example, the following line in your KERNEL configuration file would allow you to simultaneously use up to 4 vnd devices.

  pseudo-device vnd 4

The good news is that this exact line is included in the configuration file for GENERIC, the default OpenBSD kernel, so you may well be able to move forward here without having to stop and rebuild your kernel.

The tool used to configure these encrypted virtual filesystems is vnconfig(8). Other than reading the man page/s (of course), the only real trick is that you have to use the svnd ("safe" vnd) devices introduced in OpenBSD 2.1 rather than the regular vnd devices. The main difference between the two is that access via svnd devices goes through the buffercache while access via vnd devices bypasses it. And since cache-coherency is needed for disk[-like] access, the svnd variety must be used here.

When using a file as a disk, the file needs to be of static size. One way to create a file of a specific size is to use the dd(1) command to put as many empty bytes into it as required in order to reach the desired size. Using 1024 byte blocks for simplicity, here is an example.

  # dd if=/dev/zero of=/lame/secrets/cryptfile \
      bs=1024 count=51200

This command will create an empty (or, more precisely, a sparse) 50 Meg file called cryptfile in the /lame/secrets directory. Since a mount point will be needed in order to use it like a disk, we should go ahead and make this as well, something like so ...

  # mkdir /lame/secrets/cryptmnt

Now, the vnconfig command is used to associate the file, cryptfile with an svnd device like so ...

  # /usr/sbin/vnconfig -ck \
      -v /dev/svnd0c /lame/secrets/cryptfile

This command will prompt for a password to be given to this encrypted virtual filesystem. Enter something good.

Now, the disklabel(8) command can be used to partition this file up as desired (just as if it were a real disk) or, if it's full size will be used as a single filesystem (the usual case for such a file), you may as well not bother with disklabel since it's full size will be available as partition c by default anyway.

Now, the newfs(8) command must be used to make filesystems on any partitions that will be used since they will need filesystems on them (again, just like a real disk) in order to be used as virtual filesystems.

Once the foregoing is done, the partition/s of the cryptfile virtual disk can be mounted for use like any normal filesystem. The password will have to be provided, of course, upon each mount attempt in order to successfully make the mount. And upon unmounting, all that will be left for prying eyes is the encrypted file, cryptfile. :-)

Now, for the sake of simplicity, let's assume we left all the space in file, cryptfile, in the one big partition, c, which can now be mounted like so ...

  # /sbin/mount /dev/svnd0c /lame/secrets/cryptmnt

That's all there is to it. Now you can just cd to /lame/secrets/cryptmnt and write whatever top secret manifestos you have in mind there. When done, simply unmount the file and unconfigure the previously configured cryptfile<-->svnd association for it as follows...

  # /sbin/umount /lame/secrets/cryptmnt
  # /usr/sbin/vnconfig -u -v /dev/svnd0c

Adding HMACs

The fact that no HMAC is kept on these virtual encrypted filesystems is not that big a deal IMNSHO. If you are extremely paranoid about this though, it should be relatively easy to rewrite the cryptfs script provided here as cryptfs.pl in perl and add this feature via either the Digest::HMAC_SHA1 or Digest::HMAC_MD5 perl module, depending on your tastes, both of which are included in OpenBSD's p5-Digest-MD5 port/package. If you do that, let me know. Otherwise, I'll get around to it myself sometime. :-)

Good Luck,

-- ~~Kyle Amon~~

BackWatcher, Inc.
Information Security Solutions
http://www.backwatcher.com/
support@backwatcher.com
813-655-8056