My previous posts on Encryption have focused on Public Key Encryption and e-mail. Users of PGP already know that they can extend the same practice to individual files. Mostly, this is used to provide a cryptographic signature on a file, to prove that it has come from a reliable source, but you can also encrypt a file such that it can be decrypted only by a specific user. This has it’s uses, but it quickly grows out of hand, and doesn’t really work well for the file-system level. Plus, the decryption of a target file places the decrypted version of the file on the hard drive, which could then be recovered at a later time by a forensic analysis of the volume. A good Mass Storage encrpytion scheme must decrypt the files in real time, storing them in memory while in use.
Mass Storage Encryption is of great importance to most large enterprises. Particularly with the proliferation of laptops and removable mass storage. Filesystem Encryption seems to come in two flavors:
- Full disk encryption which encrypts an entire hardware volume
- [Filesystem Encryption(http://en.wikipedia.org/wiki/Filesystem-level_encryption “Wikipedia”) which encrypts files and folders on a filesystem
Of the two, Full Disk Encryption is vastly superior, as most Filesystem Encryption schemes don’t encrypt metadata on the files (name, size, owner, etc). This lack of meta-data encryption in a Filesystem encryption scheme leads to a number of interesting (both theoretically and practically) attacks on these sorts of encryption schemes. By anaylzing meta-data you could learn a lot about the target and their activities, but more insidious is the potential that suspected known file was encrypted by the filesystem. By knowing what the plaintext version of a piece of ciphertext is, you can calculate the key used to create the file. This wouldn’t be a completely trival task, but people rolling out this sort of encryption must be very careful what files they place in their encryption.
The Full Disk Encryption methods are vastly superior because they create an encrypted container that a filesystem is created within, meaning that the metadata remains safely hidden within the secure container. The name is only truly accurate when dealing with a hardware level encryption system, which are not very common. This is because the software encryption layers encrypt volumes, which are typically partitions, but can span multiple hardware drives, which is far more flexible. I suspect we’ll start to see more RAID controllers with on-board hardware encryption.
There are a few problems with Hardware-Level Encrpytion (HLE). First, most schemes on the market today use DES and TDES, both of which are schemes which are not considered particularly secure anymore due to small key sizes (easily brute-forced), and statistical weaknesses based on the birthday-bound problem. Second, no current HLE systems have a good method of storing the keys separately from the system. The current front-runner technology is the Trusted Platform Module (TPM), a hardware microcontroller which can uniquely identify a computer. TPM suffers from two weaknesses. For Internal Storage, such as hard drives, the drive is only safe from an intruder if physically separated from the computer which initialized it. For External Storage, such as USB Flash Drives, the drive is only usable on the computer it was initialized on. While TPM appears to have some other benifits, as a hardware identification layer for software encryption, I just don’t think it’s acceptable.
What is needed is a middle ground, but in order to achieve that middle ground, it is necessary to establish what data needs to be protected. In my opinion, any operating system or software runtime files should be considered expendable. On my Linux Box, it isn’t important to encrypt the contents of /usr, /boot, /lib, /bin, /sbin, and so on. Those are all system files, which if an attacker is able to take my hard drive, I don’t care about them getting their hands on. /var and /etc fall into a little bit more of a grey area. I would argue that /etc doesn’t need to be encrypted, since the majority of information on /etc wouldn’t be of much use to an attacker to getting access to my private data. Even having access to passwd and shadow wouldn’t be much of a danger if a reasonable password scheme was in place. /var could have some data that was wanted to be kept private. I feel tha the best way to handle this would be to create a new directory, say /secvar which /var would symlink to for the files that an organization wanted to keep encrypted (say their webroot or employee e-mail).
Such an encrypted partition would probably need to be available to all users while the system was running, being protected by the operating systems other security mechanisms. What this would protect from is the loss or theft of the physical drive. But how should it be mounted? Good passphrases are nice, but in a large organization, can be unweildy. Keeping keys on removable storage which would only be required at boot is a good soultion if phsyical access to the hardware is a reality. This is a decision which will need to be made at the organizational level depending on the organizational needs. The important thing is to keep backups of the passphrases and keys and ensure that access to those pieces of data are very highly regulated. If the keys are lost, so is the data.
The exact system used to facilitate the encryption is going to differ from system to system. I feel that this part of the encryption process can be Operating System specific. On Windows Vista and 2008, Bitlocker appears to be a good solution, and I know that Washington State University is considering it for an institutional standard. Bitlocker addresses my primary concern with TPM, actually, by forcing a user to create a backup key and/or passphrase, that can be used to move a Bitlocker volume to a new hardware platform. On Linux, dm-crypt and LUKS can provide similar functionality.
When it comes to encrypting user data, the situation gets a little messier. In a shared environment, where user data needs to be accessible by administration, the same methods discussed above should be used, as it provides access to the administration, while still giving the benifits of the encrypted filesystem. In a situation where user data should be protected, each user should have their own volume which can be encrypted (some systems can have virtual volumes that can be stored on a hardware filesystem and mounted as a loopback device, more on that later). In this case, the login process needs to be extended to mount that users personal encrypted filesystem when they log in.
The concept of the individual user data directory leads well into the next problem of the removable storage, most frequently USB flash drives. There are security risks regarding the use of removable storage within your organization, but I’m going to assume for the following discussion that it’s already been decided how the organization is going to be handling those security implications. Today, we’re going to discuss what can be done to ensure that if a USB drive is lost, the data on it is safe from prying eyes from whomever might have found it.
While an organization could certainly use the same encryption methods that they use for their hard disks, that solution is imperfect because it limits the ability to recover that data to a particular operating system. Ideally, the USB drive should be accessible from any OS that happens to have the requisite software avaiable. For this, I’m fond of TrucCrypt, which has good support for Windows, Mac OS X, and Linux. The nice thing about TrueCrypt, is that the concept of a encrypted filesystem is somewhat flexible. If you want to create an actual hardware partition or drive to be encrpyted, that is supported. Also, you can create a file which will represent the encrypted filesystem which can then be mounted. I suspect many users will probably create an encrpyted file to store their encrpyted filesystem for two reasons, mainly because of Windows.
On Windows, a USB Drive can not have multiple partitions, so it would be impossible to have an unencrypted drive to store, say, a version of TrueCrypt that didn’t need to be installed, and then the second encrypted partition. By a no-install version of TrueCrypt available for all platforms you’d be using the drive on, you can ensure you’ll always have access to your data. The biggest weakness of this approach, is that the most portable Filesystem, FAT, only supports files of up to 4 GiB in size. As drives get larger (8 GB drives are not terribly expensive these days) that could be an inconvenience.
TrueCrypt has some interesting features, such as the creation of “Hidden” volumes within volumes, which allow you to give an assailant a password to your filesystem which will have data that looks interesting, but really isn’t, while keeping the real data safe. While interesting, I’m not sure how useful it would be in practice, but then I’ve never had data so secret I thought someone might kill me for my key, which the TrueCrypt Docs seem to indicate they feel is a possibility. Still, might be a useful feature, even if you aren’t in the NSA.
At the end of the day, the biggest rule regarding filesystem encryption is that you should be doing it. At least for any sort of portable drives. You should do it in such a way that only certain people can access it, be it through the use of strong passphrases, or encryption keys on USB devices (which Bitlocker requires, if you don’t have TPM). If using encrpytion keys on a USB Drive, the encrypted filesystem and the USB key should be together for as short a period of time as possible. As with encrypted e-mail, there is a level of education this will require for users, but ultimately, the increase in protection of your vital data is worth any minor inconveniece it might cause your users. In truth, it can bring more convenience to them, as you can be more trusting of them taking data out of the organization to work on.