Encrypted FreeBSD USB boot disk

It appears that USB attached storage devices resemble what floppy disks were back in the nineties. Back then, transporting floppies from one computer to another was very common. Unintentionally spreading malware and losing disks also. The risk of spreading malware has also remained the same since then. Losing disks means losing data. Today, online (cloud) storage is replacing USB storage to some extent. Especially for transporting data from one computer to another. Cloud storage is not always the right solution for this purpose as some data may actually be confidential and should be kept private at all times. Encryption is a tool that can do just that. Data encryption was once strictly regulated and generally a time consuming process. Which made it more suitable for intelligence agencies, military and diplomats. Until Phil Zimmermann unleased PGP to the world. Nowadays, if you have a computer connected to the Internet, then you have easy access to really sophisticated encryption software. This post is about “transparent” full (hard) disk encryption using FreeBSD.

Encryption is extremely useful to keep data to yourself. These days, too often, without much thought, I – like most people – trust most of my entire life on the correct and accurate functioning of computers… and the people that operate them. Think for a minute about what is and what isn’t on your computer and for what reason. I bet you’re using your computer for more tasks than you thought. E-mails, photo’s, movies, various documents ranging from PDF’s from insurance policies to bank account information. All these personal belongings are assumed to be safe when they are on your computer, but if you copy them to a mobile/portable storage device, such as a USB disk, the chance of losing data increases. And thus, requiring encryption to protect them. If you are connected to the Internet, this is of course not sufficient, but more about that later.

USB flash disks are very interesting for backup purposes. They are relative inexpensive, and storage capacity is increasing rapidly, allowing replacement copies of backups on newer disks so you can safely retire the old disk after a while. There is something that you should keep in mind: Whatever program you’ve used to create your document may not be available at some point in the future when you try to open that document again on a different, newer computer. So, to be sure you need a snapshot copy of the environment which you’re using to edit the document. Hey, “a snapshot copy”, deja vu! This is based on the assumption that your newer computer will allow you to boot from your USB flash disk, and is compatible with the software on that disk. But since almost every desktop is based on x86 compatible hardware, that assumption is a fairly safe bet.

Creating a snapshot copy of FreeBSD is described here. You can find the modified version here: Secure boot disk. This creates 4 encrypted UFS filesystems: /boot, / (the rootfs plus the most important directories of /usr), a second copy of / and the rest of diskspace as /usr/local. Only /boot and the root filesystem is copied of your running FreeBSD instance.

Booting an encrypted disk resembles the “chicken and egg” problem: You need to start unencrypted software to decrypt the encrypted software. In FreeBSD-land this means that /boot cannot be encrypted. /boot contains the heart of the operating system (kernel) and its modules and some startup parameters. This is an Achilles’ heel, because if the kernel is replaced with a version containing a backdoor or trojan, then all is lost. Fortunately, /boot is static, meaning that after creation, there are practically no modifications to it unless the kernel itself is updated/replaced. A running FreeBSD system has no need for /boot, assuming all kernel-modules are loaded at startup. The script calculates a cryptographic hash (checksum) of the filesystem containing /boot and stores that in the encrypted root filesystem, allowing you to check if anything was altered. Mounting /boot with read-write permissions is sufficient to alter the filesystem and no longer match the checksum, which should raise concern about the integrity of /boot. You could argue that this is not enough for true tamper-detection, as an attacker would likely modify, remove or bypass the checksum all together. So if you really need to be sure if you can safely start whats on the disk, you would actually need a second disk containing the same software allowing you to compare results before continuing… I can only recommend making multiple backups if you’re using the script 😉

As history has shown, most of the rootkits are placed inside the root filesystem. A shadow copy of the root filesystem is in the third partition of the disk, for easy reference. The second slice (Unix-speak for partition) contains the checksum of the first slice (/boot), and the third slice (shadow /) contains the checksum of the second (/). Following that method, the fifth slice would contain the checksum of the fourth, but as there are only four the last one is skipped. The script leaves the fourth slice blank, allowing you to use that for whatever you need to place there.

Epilogue

There are numerous assumptions being made in this post about what is “secure enough”. Each assumption is a potential weakness, and some of those are risky! As I don’t want to be bothered to type in a passphrase on the console of the system when the system is starting, I removed the passphare from the key-files used to decrypt the filesystems, making it behave as if there was no encryption in the first place. These key-files are stored in the unencrypted /boot filesystem. Without a passphrase to protect them, these are useless for protection as anybody can read the keys and mount the encrypted filesystems with them and read its contents or… simply boot the disk! You can only use key-files securely if they are on a medium that cannot be copied such as a (pin-code protected) smartcard. But even if you would have a smartcard for a key: before you attempt to boot the USB disk, you would need to verify its integrity with an identical twin. How would you otherwise know to trust the binaries? Even if you did all that, there is still a chance that your system was compromised before you created the copy on USB disk, especially if you are or were connected to the Internet.

Encryption without properly protected keys is essentially an April fools joke; it’s utterly useless for keeping files confidential! It is like writing your username and password on your keyboard. Although the script is useful to some extent, make sure you adjust it to suit your needs.

A final remark: Losing a key-file means losing an entire slice, with a very small chance of a successful recovery. This is especially painful for the last slice, as it is likely the biggest and may therefor contain the most data. Store a copy of the key-files somewhere in a safe place.

 

 

This entry was posted in Crypto, FreeBSD, IT Security and tagged , , , . Bookmark the permalink.