Rate this page del.icio.us  Digg slashdot StumbleUpon

Disk encryption in Fedora: Past, present and future

by W. Michael Petullo

These days, data is mobile. Every day, sensitive corporate data leaves a company’s headquarters on a flash drive or an employee’s laptop. Regardless of where it is going, mobile data can be an I.T. department’s worst nightmare.

In fact, the 2006 “CSI/FBI Computer Crime and Security Survey,” a joint effort by the San Francisco office of the FBI and the Computer Security Institute, named laptop theft as the third-largest source of financial loss in the computer security domain. This survey reports the results of 426 companies. While most security threats documented by the study decreased, losses from laptop theft have increased since 2005. “Data protection (e.g., data classification, identification and encryption) and application software (e.g., Web application VoIP vulnerability security)” were cited as the “most critical computer security issues in next two years” by 73 respondents.

The data on a stolen laptop may be far more valuable than the device itself.

One of the most important computer security issues today is laptop theft. The data on a stolen laptop may be far more valuable than the device itself. For example, a stolen UC Berkeley laptop contained sensitive data about nearly 100,000 alumni. A stolen Department of Veteran’s Affairs latop yielded information from up to 26.5 million veterans. There are many examples of high-profile laptop theft, and these incidents are often very costly for companies. The cost, however, isn’t related to the hardware replacement, but to the loss of confidential information and customer security.

What if the owner could state that the data has not been compromised? What if the only loss resulting from a stolen laptop was purely material? This would certainly alleviate some of the risks behind mobile data. Disk encryption is one way to help solve this problem. Since the Fedora™ Project was announced in 2003, many disk encryption technologies have been added to the Fedora platform.

The kernel

There are several disk encryption interfaces available for Linux. Competing projects have encryption as a filesystem implementation. In these cases, an alternative to ext3 (or other common filesystems) is used and encryption is performed by the filesystem itself. The cryptoloop and Jari Ruusu’s Loop-AES encrypt using a different technique. Here, the kernel’s disk loopback device is extended to provide the encryption. Cryptoloop was distributed with the Linux kernel until early in the 2.6 series. It was replaced by dm-crypt in 2.6.4. The dm-crypt code uses the kernel’s device mapper interface to implement the encryption. The dm-crypt interface now seems to be preferred by the kernel developers. The Fedora Project has included it since Fedora Core 2. The rest of this article will focus on technologies that build on top of dm-crypt.

Cryptsetup

Although dm-crypt provides a solid disk encryption interface within the kernel, the device mapper’s userspace tools are not very user friendly. The dmsetup tool can be used to set up an encrypted disk. However, dmsetup is a general tool that is used for device mapper volumes. Christophe Saout developed a way that focuses on setting up dm-crypt devices. This tool, cryptsetup, provides a simpler interface than dmsetup and was first included in Fedora Core 2 (See Bugzilla #120487.)

The following command creates a plaintext dm-crypt device, /dev/mapper/test, for a backing partition, /dev/hdaX. The AES is used in cipher block chaining mode:

cryptsetup -c aes-cbc-plain create test /dev/hdaX

Once /dev/mapper/test exists,treat it as any other block device. This device and it’s backing unit, /dev/hdaX, are two views of the same device. One view is plaintext and the other is ciphertext. So, if one creates a filesystem on /dev/mapper/test, and then looks at /dev/hdaX, then they will see an encrypted view of the same filesystem. The following command will create an ext3 filesystem on /dev/mapper/test:

mkfs.ext3 /dev/mapper/test

This filesystem may be mounted and unmounted using:

mount /dev/mapper/test /mnt/test

umount /mnt/test

Finally, after the filesystem is unmounted, its backing device may be removed. This leaves only the encrypted /dev/hdaX. The only way to view the plaintext data is to recreate /dev/mapper/test using cryptsetup -c aes-cbc-plain create test /dev/hdaX and a passphrase. The following command removes /dev/mapper/test:

cryptsetup remove test

The dm-crypt interface and the cryptsetup utility provides the functionality necessary to make encrypted disks usable by the Fedora Project. However, cryptsetup made it difficult to build since users must remember a disk’s encryption parameters, including the cipher used.

Linux Unified Key Setup

Clemens Fruhwirth modified cryptsetup to support a standard he developed called the Linux Unified Key Setup (LUKS). LUKS embeds encryption information in a partition header, simplifying the use of the disk. Now the user doesn’t have to remember the cipher or cryptographic mode used. LUKS also adds support for multiple keys and other features. The cryptsetup-luks utility first replaced cryptsetup in Fedora Core 4 (See Bugzilla #147313.)

The following command places a LUKS header on /dev/hdaX (this command is only executed once, to initialize the header):

cryptsetup -c aes-cbc-plain luksFormat /dev/hdaX

Once a LUKS header exists, a plaintext dm-crypt device may be created for the encrypted backing partition. Because the algorithm AES and mode cipher block chaining were written to the disk’s LUKS header, these parameters do not have to be specified each time the plaintext device is setup:

cryptsetup luksOpen /dev/hdaX test

The plaintext dm-crypt device may be formatted with a filesystem, mounted and unmounted as before:

mkfs.ext3 /dev/mapper/test

mount /dev/mapper/test /mnt/test

umount /mnt/test

Finally, the following command removes /dev/mapper/test:

cryptsetup luksClose test

HAL Integration

LUKS and its encryption parameter partition header provides a great foundation for higher-level tools. For example, LUKS allows the implementation of David Zeuthan’s proposal for an encrypted disk system. It was David’s vision that encrypted disks should be easier to use. He proposed that the Hardware Abstraction Layer (HAL) be modified to detect encrypted disks. When an encrypted disk is plugged into a computer, the system should automatically prompt a user for a passphrase and mount the disk, just as HAL and its helpers mount regular disks.

Fig 1. Screenshot shows HAL-identified LUKS-encrypted disk.

Fedora Core 5 included this functionality. HAL is now able to pull all encryption parameters from a LUKS header so a user only needs to provide a passphrase. Figure 1 is a screenshot showing that HAL now identifies LUKS-encrypted disks. Notice that the volume.fstype is crypto_LUKS. For more information about HAL’s LUKS support, see Adding encryption support to HAL: A user’s experience with Fedora development.

In order to make formatting LUKS encrypted disks easier, I wrote the luks-tools suite. For example, gnome-luks-format provides a graphical tool to format encrypted disks. The luks-tools suite was accepted into Fedora Extras around the time Fedora Core 6 was released (See Bugzilla #166035.)

Protection of swap

A disk’s swap space poses a problem on systems with encrypted disks. If data from an encrypted disk is loaded to memory and then swapped to another disk, that data is generally written in plaintext to the swap disk. Obviously, this defeats the purpose of the encrypted disk. Although plaintext data in memory is lost when a computer is turned off, data written to a swap disk may survive a power cycle. A BugTraq mailing-list thread titled “Mac OS X stores login/Keychain/FileVault passwords on disk” documents a variant of this problem. One solution to this problem is to encrypt the swap disk.

Support for an encrypted swap disk was implemented in Fedora Core 6 (See Bugzilla #127378.) The system initialization script, /etc/rc.d/rc.sysinit, now looks for a file called /etc/crypttab that defines encrypted disks. The following crypttab defines /dev/hdaY as an encrypted swap device, protected using AES:

swap /dev/hdaY /dev/urandom swap,cipher=aes-cbc-essiv:sha256

The format for a crypttab entry is:

[name] [cryptodevice] [keyfile] [options]

The example above causes the system to create a plaintext dm-crypt device named swap for the encrypted backing device /dev/hdaY. The key file used for this process is /dev/urandom. A random keyfile ensures that swapped data will not survive a reboot because a new random key is used each time the system starts. Because the swap option is specified, mkswap will be run on /dev/mapper/swap and the device will be used as swap space.

Protection of the root filesystem

Thus far, this article has discussed encrypting portions of a filesystem. For example, removable disks may be encrypted to protect their contents. In addition, swap space may be encrypted. In some instances, one may wish to encrypt an entire filesystems, including the files required to boot. Though this feature is not yet supported by Fedora Core, I am contributing to the effort to implement it (See Bugzilla #124789.)

Our effort has created a patch for mkinitrd, the tool that creates a system’s initial ramdisk (initrd.) The initrd is an extremely lightweight filesystem that the Linux kernel uses to boot. The initrd can load kernel modules or perform other actions required before the real root filesystem is mounted. Our modifications to mkinitrd cause the script to detect an encrypted root filesystem and create a special initrd for it. This initrd will obtain a passphrase and unlock the encrypted root filesystem before mounting it.

Currently, one must manually create an encrypted root filesystem using an existing Fedora Core installation and the mkinitrd patch. Instructions for this are included in Bugzilla #124789. Once the Fedora mkinitrd supports this feature, I hope to see anaconda modified so that it can create an encrypted root filesystem as Fedora Core is installed.

More technical details on how a system boots using an encrypted root filesystem may be found in Encrypt Your Root Filesystem, published in the January 2005 issue of the Linux Journal. This article also discusses some of the potential attacks on an encrypted filesystem and how to figure out what needs to be defended against.

Conclusion

In this article we have discussed the past, present, and future of disk encryption within the Fedora Project. After many years of security feature development and testing, the Fedora Project now has a disk encryption platform. Creative developers and administrators can use these tools to secure information, even on the most vulnerable and mobile hardware platforms. From supporting the kernel to encrypting the entire filesystem, the Fedora Project provides solid disk encryption capabilities.

39 responses to “Disk encryption in Fedora: Past, present and future”

  1. Peter StJ says:

    I wonder: If we decide to use the Swap partition encryption will it be possible to suspend to disk functionallity. As explained when booting before initialising the swap it is checked if it going to be encrypted and encrypted using random value. If this is true, then when we try to resume, what happens? As I understand it the system is hibernated to the swap partition and it works just fine in FC6. So what if we want to have encryption of the swap + hibernate?

    Thanks

  2. Bruno Wolff says:

    Is there a list of taks that need to be done to get this into Fedora 7?

  3. Miro Halas says:

    I recommend to also look at TrueCrypt (http://www.truecrypt.org/). It is open source project and allows both encrypted filesystem in a file as well as encrypted raw file system in a disk partition. What is also nice is that it is cross platform and work both on Win (with nice gui tools) as well as Linux. This is especially nice on removable media which can be used under various operating systems.

  4. W. Michael Petullo says:

    In response to Bruno, since this article was submitted, more encrypted disk support has been formally proposed for Fedora 7. Please see http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems.

    Peter, an encrypted swap partition does present a problem for Fedora’s suspend to disk feature. Using a random key is not compatible with suspend to disk. This could be fixed if one used a key that remained consistent across boots. Certainly, this is not much of a leap if one is already using a persistent key to unlock a root filesystem. Although I have not worked with suspend to disk, I believe others have tried to combine the feature with an encrypted swap partition.

  5. Bruno Wolff says:

    I have read the encrypted file systems page already. In fact I got emailed a notice of the change for the link to this article.
    I have also read through the referenced bugzilla entries.
    What I was hoping to find was a more detailed list of things that need to get done in order for this to make it into Fedora 7. It seems like there may only be a coupld of people working on this and that other people may not be able to effectively help this close to the test 1 release. But I mostly expected that testing installs would be the only area where I would be able to help at this point anyway.

  6. Bruno Wolff says:

    I don’t think TrueCrypt is the right way to go here. It makes more sense to split the encryption from other aspects of the file system since they are essentially orthogonal. That way you can get the properties (e.g. journaling, indexed directories, handling of small files) of whichever file system you want without there having to be an encrypted version of each one.

  7. Miro Halas says:

    I cannot speak to the implementation or technical details since I do not have enough knowledge about details of it, but I can speak regarding the features from the user perspective. Encrypted file system/disk partition is a great feature, but what makes TrueCrypt especially useful for me are the following features I appreciate the most:

    1. Great GUI allowing to easily very easily even for novice users install, configure, create and mount the encrypted filesystems. Once mounted it works seamlessly as any other file system.
    2. Cross platform out of the box. My encrypted removable media work everywhere I work regardless of platform or OS. It is great to have ability for example to ship encrypted flash drive or file without worrying what platform the addressee uses.
    3. Encrypted file system within a file. This provides an easy way to store data I care about encrypted without the need to repartition my disk. It also provides for easy and safe experimentation since if something goes wrong, I can just remove the file and start over. This feature allows easy backup and handling from user perspective, since user doesn’t have to know anything about file systems, it just knows that all the encrypted files and data are hidden within that one file. It also allows to easily create multiple different encrypted volumes for different purposes with different credentials without messing with the disk partitions.
    4. Hidden volumes. Ability to create hidden encrypted volume within encrypted volume allowing for plausible deniability.

    Regardless of what is the technology used for disk encryption, I would love to see the above 4 feature sets provided out of the box in as easy way as possible.

  8. Bruno Wolff says:

    I think you might be given TrueCrypt too much credit.

    Item 1:
    There is nothing preventing making GUI interfaces for setting up dm-crypt file systems. It may not be there for Fedora 7, but I expect it to be part of anaconda’s GUI at some point.
    dmcrpyt file systems do work seemlessly.

    Item 2:
    Things are only as cross platform as supported by the devlopers. There are plenty of OS’s that TrueCrypt doesn’t run on, you (and most people) just probably never use them.
    The encrypted partition format used by dmcrypt could be supported on windows. The question is whether or not some one has enough motivation to do so.
    Certainly for some people this will be an important feature, but I don’t see it is something that most people need, as copying file systems between systems is rare.

    Item 3:
    You should be able to use loopback file systems to put a dmcrypt file system inside of a file in another file system. This might be useful for experimentation, but in general you really want to have all of your file systems encrypted, to prevent mistakes. So you shouldn’t need this in production.

    I wouldn’t count on backups working if you are just copying the file without taking special precautions. If updates are happening to the encrypted files stored on that file while the backup is being done, you might find a lot of the data inaccessible. This is also going to make it hard to do incremental backups. You really want the back up program to have access to the files’ metadata and encrypt the backup tapes. Certainly you can still look inside the encrypted file systems to do backups with TrueCrypt, but that negates the simple copy the file to back up the file system strategy.

    Item 4:
    I wouldn’t count too much on hidden volumes. It is possible to figure out how much space data should take up and if your data is taking up a lot less than it should, you are going to have to do some fast talking. Metadata in the TrueCrypt file system is also likely to give away the fact that there is a hidden partition as well. Even though they claim you can’t tell if some data is a TrueCrypt volume, once you’ve given up a password for your cover volume, the adversary should be able to tell there is a lot of space not being used by that volume.
    If you are just trying to fool a customs agent or something, you can probably get away with just deleting a partition entry and then putting back later.

    I didn’t see any information if TrueCrypt supports Write Barriers. This is important in cases where you care about what happens if the system crashes while doing updates. I would be very leary of running a database system on top of TrueCrypt. While there are some things relating to write barriers that you need to be careful about (support with limited raid modes in software raid and a possible issue with the changes to dmcrypt that went into 2.6.19 on smp machines) when using stacked block devices on linux, the intent is that things are supposed to work correctly (and eventually should).

    It sounds like TrueCrypt is a good solution for portable media (particularly in the short term), but I believe that dmcrypt is a better approach for Fedora to be moving in. That doesn’t mean that I think that TrueCrypt shouldn’t be in Fedora, but rather that I don’t think it should be used when doing installs and that I would prefer that resources spent by Redhat were spent on dmcrypt in preference to TrueCrypt.

  9. Phil says:

    It’s a pity that loop-aes seems to have been largely bypassed in this article.

    Loop-aes has been the first to spot and correct vulnerabilities, ahead of dmcrypt and truecrypt. Jari Russu has been an open critic of flaws in dmcrypt but, thanks to this, some serious flaws have been fixed. But (read the linux-crypto maillist), the dmcrypt developers have not been particularly pleasant or smart in their responses to Jari’s well-aimed technical criticisms, and I (and some others) find this suspicious. Granted, he perhaps lacks some political finesse in delivering his criticisms, for example, he insists that the mainline kernel developers are deliberately supporting broken crypto implementations over his. But what if he’s right about the broken part?

    There’s no reason AFAIK that loop-aes should not co-exist with dmcrypt in Fedora, it’s just a recompiled loop driver and a patched linux-utils.

    I for one place more trust in loop-aes, and I’m not alone.

  10. Miro Halas says:

    Bruno,

    I am not a technical expert to tell you which solution is better technically. You have asked what is the to do list and from my user perspective I can tell what would like to see when implementing disk encryption user interface (regardless of what technology you choose).

    1. I completely agree that such UI is needed. I can just suggest to look at the TrueCrypt UI to see an example of what works very nicely and maybe get inspired. Also on TrueCrypt’s todo list is to implement GUI for Linux and maybe there can be common effort, which would support multiple technologies in the background (e.g. dmcrypt, TrueCrypt or loop-aes and Phils suggested). I do not think this should only be part of Anaconda since this is often needed after the system is installed. System administration applet than can be possibly reused in Anaconda seems like better approach.

    2. I completely agree. So when integrating such technology to Fedora why to do not implement the user facing portion of this to support multiple backends and let user choose.

    3. Great if it is possible. I see it as a great feature and probably other users too. I would just suggest to provide this as an easy to use feature (again, see example how TrueCrypt UI does it for an easy to use way). As far as backup, I would actually prefer backup to do not know what it is backuping and therefore recognize that given filesystem is mounted file and either unmount it and backup afterwards or do not backup until it is unmounted.

    4. I would suggest you to read more about hidden volume. You will discover that all metadata is encrypted so there is no way to recognize if it is in fact random data in empty space or hidden volume. Also the GUI used to mount the volume makes it hard to recognize for casual observer if the user is mounting the outside visible volume or the hidden volume.

  11. Bruno Wolff says:

    Miro, if you are using a hidden volume for deniability, claiming that data is just random and not an encrypted volume is not going to satisfy serious inquiry. Having a dummy volume to reveal, again doesn’t help in this case, because they will be able to tell what parts of the disk are used by the volume you did reveal and they will be able to estimate how much space the data you have shown should take up. This will make it apparent that there is other data on the drive (unless you are hiding a very small amount of data) which may include hidden volumes and whatever interrogation you are undergoing is going to continue.
    While this will work against people who aren’t looking hard, so will a lot of other things.

  12. Miro Halas says:

    Hi Bruno,

    I am not sure I understand your argument. Lets say I have 500GB disk and on it 400GB encrypted partition (or 400GB file representing encrypted file system, the argument still stands.). Let say this partition contains only 200GB of data which is pretty plausible since it is hard to get 200GB of data anyway :-). The remaining 200GB are free. I would like to understand your argument how would you recognize if the 200GB are really free or if they contain a hidden volume if in both cases the data look to the observer as a random datastream?

    Thanks,

    Miro

  13. xjlittle says:

    I read this article with great interest as I am a network engineer at a hospital. As most of you probably know we must follow HIPPA security procedures.

    In our hospital, on both servers and desktops, there is a mixture of linux and windows. As I read the article and the discussions the thought kept running through my mind of the administrative overhead of dealing with two sets of users, one running some encryption app under windows and the other under linux.

    Because of my great respect for linux developers and their attention to security I would much rather run a security app developed by them rather one developed only for windows. However I do have limited resources so I must pay close attention to things that create administrative overhead, this being one of them. I realize that you, the developers, also have limited resources and rely on people who wish to contribute their time and talent to this or any other open source project.

    Herein lies the dilemma of most people in my position, as well as the dilemma of getting linux more widely used. We would rather use linux. However windows is not going to go away any time soon. Administrators and engineers would gladly push for more linux desktops were it not for the administrative overhead. On applications such as this, if it were cross platform, it would be one more step in the right direction.

    Until that time we (admins and engineers) must fight and struggle with when to use what app and on which platform. Unfortunately that causes us to sometimes use operating systems and applications that we would rather not use knowing that they are not the best ones in a given situation. This is a constant struggle.

    The answer, it seems, then is how can the community of developers attract more developers so that the resources are available to you to develop cross platform? Is it possible to set as one of the goals of a project that the application must be cross platform?

    I am not a developer and have never started an open source project. I have no clue to the obstactles that you face other than you are probably painfully short of resources including people’s time.

    I don’t know the anwers to these questions although I suppose anything is possible. My point is that I sometimes think that developers miss the idea that as administrators we get hamstrung when trying to “sell” the use of linux on desktops because of administrative overhead.

  14. Alexandre Alencar says:

    What’s about encrypted filesystems using smart card e-CAC certificates as encriptation key?

    Thank’s

  15. Bruno Wolff says:

    Miro, the problem is that the person doing the interrogation can see that there is unused areas of your drive. They don’t know whether the data is just unused space on the drive. However you are going to have a tough time explaining why your drive has this unused space. This is pretty much the same as if you tried to tell them your whole drive was just random data. Whether or not it is true, they aren’t likely to believe you.
    You can hide small amounts of data in various ways, but if someone sees that say half of your disk drive isn’t part of any partition they are going to wonder why you would do that and come to the conclusion that you probably didn’t and that somehow you are using that space.

  16. Bruno Wolff says:

    xjlittle, if you are using dmcrypt to protect against theft of equipment, there is little need for it to be cross platform.
    File sharing won’t happen at a level where the encryption get’s in the way. The main issue would be having to have two different systems that need to be administered. But that cost might not be that significant compared to the costs you already are paying to administer two different types of systems today.

  17. Miro Halas says:

    Bruno,

    I believe your reasoning is not correct. It is very common to have large hard drives in todays computers that are only partially filled with data. The partition occupies the entire drive but just a portion of the partition is occupied by data (just because thats only how much data you have). Nobody is ever going to question why you have only 200GB of data in 500GB partition, because the very plausible explanation is that you just do not have any more data. If there is anything hidden in the unused portion of the partition (remember, that partition is formatted and ready to be used at any time and filled up in any other data) it will not attract any attention. I believe your arguments haven’t invalidated at all the idea of hidden volumes the way TrueCrypt designed and implemented it.

    Miro

  18. Bruno Wolff says:

    Miro, if all you have to do is tell the people looking there is nothing to see and they will go away, you don’t need any encryption to fool them.
    The issue is how much help truecrypt is when serious people are questioning you about your computer. Disk blocks that aren’t in any file system are going to raise red flags. Files with random bytes in them are going to raise red flags as well. Truecrypt isn’t going to be a lot of help in alleviating that suspicion.

  19. Miro Halas says:

    Bruno,

    Thanks for this discussion. I think you are misunderstanding the concept or functionality of hidden volumes and your arguments just prove it:
    1. “Disk blocks that aren’t in any file system” – nobody ever claimed that. The disc blocks storing the hidden file system are either part of file system stored in some encrypted disc partition or part of a encrypted file representing such disc partition.
    2. “Files with random bytes in them are going to raise red flags” – the files have random bytes because they represent visible encrypted file system and they are randomized and encrypted when the file system is created.

    Anyway, I think this discussion is getting off-topic :-) so we should probably just end it. I think everybody agrees that encrypted file system is a highly desirable feature and people will choose whatever implementation of it will provide the best features to satisfy their needs. I just hope that whatever implementation will be integrated to Fedora will provide at least as much as the tools that are available now or will provide ability to choose what technology to use.

  20. Jason says:

    You can also encrypt a tmp partition in much the same way as swap. If you do, you’ll get a “FAILED” message when booting during the “mounting local filesystems”, but the tmp partition will be mounted a little later. This is because the “chicken and egg” problem mentioned in rc.sysint. See the crypttab man page for more information about the tmp option.

    On another note, encrypting the root partition is great and I’m looking forward to that ability being added to Anaconda. However, most of my servers are colocated so I don’t have console access when the server reboots. Has anyone considered putting the ability to remotely enter the LUKS passphrases during boot? Ideally, some networking could be started before / is mounted and the admin could connect via ssh and enter the passphrase. This would require adding some components to the /boot partition (or wherever the server is booted from) but seems feasible.

  21. Anand Vaidya says:

    Debian testing (etch) installer CDs can install a completely LUKS encrypted system. That includes, swap, root, home and any other partition you create. Except /boot, which cannot be encrypted.

    Why not Fedora copy code/ideas from Debian?

  22. Tarjei Huse says:

    Hi, the main issue wrt to encryption is that the user has to remember an extra passphrase. I await the day when the encrypted disks are mounted on logon so that the user can enter his password once on logon and still be secure. That shouldn’t be hard.

  23. Mark says:

    In response to some of the comments posted, I would like to add some thoughts of my own.

    This article opens: “These days, data is mobile. Every day, sensitive corporate data leaves a company’s headquarters on a flash drive or an employee’s laptop. Regardless of where it is going, mobile data can be an I.T. department’s worst nightmare.”

    There is no mention of running lights-out servers with encrypted file systems. Whilst these are all perfectly valid, and useful topics for discussion, I feel they are off-topic for this article.

    Coming back towards “mobile security”, personally I believe cross platform is highly desirable. That’s not to say essential, but I doubt there are many people running Linux and ONLY Linux on a laptop.

    For reference, TrueCrypt can support FAT, FAT32 and NTFS. It is rumoured to also support ext3, and I don’t see any reason why it can’t support other filesystems inside the volume. http://www.mepis.org/docs/en/index.php/Truecrypt

    Tarjei when you say “the main issue wrt to encryption is that the user has to remember an extra passphrase”, why is that such a major problem? If you’re security conscious enough to want this grade of encryption, you probably wouldn’t trust a single password to provide access to ALL your data, would you? If someone says, “can I just borrow your laptop to check my email”, do you really want them to automatically have access to all your encrypted files?

    On the subject of obfuscation and hidden volumes, Miro is completely correct IMHO. TrueCrypt by default “slow formats” the *entire* volume with random data, not zeros. That means the entire volume contains random data, and it’s near impossible to distinguish what contains “real” files, and what contains gibberish, effectively hiding the free space.

    If someone reading this can tell me when they were last interrogated to the extent that using dm-crypt or any other technology would have provided a somehow “better experience” than using TrueCrypt (or any other product), please do… personally, I think life’s too short to worry about it to that extent!

    I haven’t seen any performance benchmarks for dm-crypt, but whilst encrypting swap space is justifiable in some highly secure circumstances, I think it would have a significant impact upon performance. Using on the fly encryption typically eats between 25 and 50% of the CPU time of a single core, meaning that battery performance takes a significant hit. Some people will be paranoid enough to want everything they own encrypted, and yet others complain of having to remember more than one password, what this highlights is that user’s requirements vary considerably, and I personally would be happy to see more than one option available.

    Mark

  24. Eric Hopper says:

    The issue of key management is glossed over here, and none of the commenters have mentioned it so far.

    IMHO, relying on a key that a user can type in on the keyboard is foolish. Keys of that nature are likely not strong enough to stand up to the attack a determined competitor is likely to be able to launch against the encryption on a hard drive.

    They key either needs to reside on a separate device or needs to require some sort of network authentication to retrieve. IMHO, a separate device is more risky because it can be stolen right along with the laptop. But if the key is behind some sort of network authentication, the company’s network admin can monitor requests to retrieve the key and easily shut down a particular login completely if suspicious behavior is detected or the laptop is reported lost or stolen. This allows the key to have a full 256 (or however many) bits of entropy instead of the 20-40 bits you’re likely to get with a key derived from a password.

    This also should be combined with intelligent key management in the kernel that makes it hard for an attacker to keep a key in memory. For example, the key should probably be kept in a couple of pieces in memory and combined via an xor operation when a block needs to be decrypted, then the combined version destroyed. Keys should also have expiry times, and those times should be kernel enforced as well.

  25. Jason says:

    Key management is handled with LUKS. The actual key used to encrypt the data can be 256 bits and is stored on the disk encrypted with the passphrase. The LUKS header has room for eight passphrases (key slots) so different users can have different passphrases (e.g. you could have an admin passphrase as well as the user passphrase). This allows passphrases to be changed without having to re-encrypt the disk.

    That said, I agree about the need for network authentication capabilities (see my earlier post #20). The problem for mobile devices is that they would need to have access to the admin server in order to boot. That may be difficult for someone wanting to work on a laptop in a car. Especially since encrypting the disk takes away hibernation capabilities (from what I’ve heard).

    dm-crypt does not require LUKS so it would be possible to get the key from the network if only we could get to the network before mounting /.

  26. Greg says:

    Some thoughts to add to the discussion:

    Regarding TrueCrypt:
    (I have used and developed with TrueCrypt for a few years now, so I want to lend some insight. Warning, can-of-worms about to be opened…)

    a) Hidden volumes: Miro and Mark are correct. The default setup with TrueCrypt creates a hidden volume properly “hidden” within the bounds of the apparently unused, high-entropy “free space” of a normal (non-hidden) volume. Since all of the free space is encrypted in the normal volume anyway, the hidden volume is normally indistinguishable.

    That being said, there are a NUMBER of things about hidden volumes that make them detectable, almost all of which are caused by user metrics that occur during usage. In this way they are more “snake-oil” than security where most lay-users are concerned. Furthermore, for technical reasons hidden volumes are limited to extremely simple filesystems (such as FAT); this severely limits their usefulness. However, these points are somewhat OT so I won’t discuss further here.

    My point is that hidden volume support is NOT a high-priority feature for an encryption framework IMO, but it could certainly be added to any of the frameworks discussed in this article.

    b) So called “cross-platform”: TrueCrypt volumes follow a very similar model to dm-crypt/LUKS. Therefore, the container is abstract from the encryption layer, as well as the data stored within the encrypted blocks. Therefore, it is capable of using any filesystem for which a suitable driver has been implemented.

    However, due to the strong Windows focus and origins of TrueCrypt, combined with the filesystem limitations of Windows and those of writable NTFS volumes anywhere else, the only true cross-platform capability TrueCrypt has today is simple FAT partitions between Windows and Linux. This may be fine for small flash drives and similar, but in widespread usage this creates obvious, significant cross-platform problems. Furthermore, Mac users and other operating systems are out in the cold (no support to date and nothing planned that I have seen).

    c) Problems with TrueCrypt that DM-Crypt, LUKS, loop-AES, etc. do NOT have:
    TrueCrypt has a number of problems IMHO– problems that are not shared by its counterparts mentioned above.

    1) Secretive, hidden developer community: The controlling project developers and the so-called “TrueCrypt Foundation” are hidden behind an anonymous screen of Internet tools. Their “foundation” doesn’t seem to be registered ANYWHERE or tied to any physical location or official entity. Their identities, names, backgrounds, countries-of-origin, etc. are unknown to anyone but their inner-circle and they refuse to address this issue (or even to explain themselves). This kind of black-hat persona certainly doesn’t lend itself to the trust of a corporate/business world, for good reason.

    Furthermore, they rule their community with an iron fist and do so inconsistently. This makes it extremely difficult to maintain a normal support atmosphere there (would-be community members leave and abandon the project on a regular basis).

    2) Cumbersome, antiquated licensing terms: TrueCrypt was born out of the OLD Encryption-For-The-Masses framework (e4m) and contains the work of several other authors/packages with inconsistent licensing conditions. This has caused them trouble in the past, for example when they tried to move their product to the GPL (unsuccessfully).

    3) Information control issues: Forums will be suddenly taken offline, apparently deliberately, as certain critical discussions occur. This occurs frequently whenever a new version is released. At the very least, this makes it very hard to support the product properly as a member of their user community, let alone the trust issues this causes.

    Furthermore, there are no published bug reports or vulnerabilities listed anywhere except for whatever makes it into their forums and isn’t deleted. Their bug submissions are only accepted through a private Web form on their site.

    Finally, certain forums aren’t even visible for public viewing unless you first register. No explanation has been given for this.

    For all these and many reasons, I now favor the work done in the “open” world by these other projects and I will no longer personally support TrueCrypt as an encryption platform. If you want the time/effort of folks like myself, you’ll stay away from the TrueCrypt-style tactics I’ve described.

    Moving on…
    ————-

    Regarding benchmarks and CPU usage:

    Mark suggests that using on-the-fly encryption “typically eats between 25 and 50% of the CPU time of a single core.” I wish to point out that giving a percentage like this is extremely inaccurate overall and very subjective. The metrics of each system and each OTFE package significantly affect the overhead required.

    Furthermore, my particular testing with said OTF encryption packages has never consistently produced a CPU overhead of this magnitude. Perhaps my systems are powerful enough that I haven’t seen these results, but I’m not running anything THAT new or powerful.

    For what it’s worth…

  27. Eric Hopper says:

    For a boot volume encrypting with just a passphrase is OK. But, IMHO, if you are encrypting /home/user you should do something a lot stronger if you want something that will stand up to willful corporate espionage.

    If your threat model is the random person one the street who will get the laptop and grab whatever’s on it that’s easy to get, then a passphrase is likely fine. But if your threat model is even a moderately funded attacker, you need something stronger or you’re just fooling yourself.

    Which reminds me, if a distribution is really going to have top quality support for disk encryption there should be an easy way to mount a home directory on login, and a flexible way of obtaining the encryption key to do the mounting. Really top notch support would have a way of suspending all the processes using a filesystem when the encryption key for it expired and a nice dialog asking for the passphrase again to get a new one.

    As for CPU usage and all that… I suspect that hardware AES support is going to be quite common in 5 years. This won’t be nearly as much of an issue then.

  28. Steve H says:

    This is an interesting article and discussion. Being new to Linux – installed Fedora two days ago to learn about Linux and possibly transition to it from Windows – much of the article went over my head but I hope to understand more of it as I learn more about Linux.

    You are discussing a couple problems that may not be all that difficult to deal with.

    1.Encrypting the entire file system requires entry of the key during the boot process.

    I use Trucrypt to secure may financial information on my home PC. The way I handle my Truecrypt key may help in this situation. I created a text file by using the random password generator at http://www.grc.com to generate many passwords pasted one after the other. That password generator creates 64 character passwords using all the characters that can by typed on a US English QWERTY keyboard with and without using the shift key. I selected a key from a large multi-line section of text that does not begin or end at the beginning or end of a line of text. I copy the key from the text file into Truecrypt and delete characters that are not really part of the key and mount the Truecrypt ‘partition.’

    It should not be difficult to have the operating system display a large text file created when the encryption is initiated and allow the user to copy their key from a portion of the file and paste it into a text box for use as the key. If the key length can be any number of characters within a large range of allowable lengths this method should be fairly secure.

    2.Clear text from an encrypted file may remain in the swap file when the system is suspended or hibernated.

    I have my Windows system set to automatically wipe the swap file when the system is closed, suspended or hibernated. If the Linux suspense file only contains the names of open files, the applications using the files and the focus point for each file open at the time of suspense then there should not be any clear text in that file.

    Not being a security expert or a Linux developer I may be way out it left field but this may help.

  29. Bruno Wolff III says:

    My comments about true crypt and hidden volumes weren’t saying that you couldn’t distinguish between random data and hidden volumes but that you could tell that the revealed volumes weren’t using all of the space and so that the deniability feature wasn’t really all that useful.
    If people were seriously analyzing your drives they would see there was more potential encrypted data if a significant part of the drive was unaccounted for and your interrogation was going to continue. Claims that the rest of the space was just random data aren’t likely to be believed under those circumstances.
    For the average person looking at a PC at a checkpoint, truecrypt’s hidden volumes are overkill. Those people would be easily fooled in a number of ways.
    So that the hidden volume feature of TrueCrypt isn’t a big reason to prefer it over dm-crypt.
    The interoperability is really only important for removeable media. If you want to make data on hard disks available over the network, you can use samba over an encrypted tunnel and not have to worry about the native file systems be used.

  30. W. Michael Petullo says:

    Eric Hopper, one may use pam_mount to mount an encrypted home directory. See an article I wrote for the Linux Journal titled “Implementing Encrypted Home Directories,” http://www.linuxjournal.com/article/6481.

  31. E.A.H. says:

    Regardless of your approach, hidden volumes in TrueCrypt represent snake-oil and the illusion of security. The concept encounters a catch-22 situation where it suffers from either a known-plaintext attack against the metadata (identifying header information) or a situation of IMplausible deniability. Neither alternative is acceptable and both represent serious problems with crypto implementation.

    Until TrueCrypt is reviewed by reputable experts in the field (Bruce Schenier, et al) the product is suspect, anyhow. Implementing crypto properly is extremely complex and subject to numerous pitfalls for non-experts. Little is known about key-handling, for instance, in this product. These types of “unknowns” are the source of many errors.

    -Me

  32. Billy Huang says:

    xjlittle:

    I read your note above about using HIPPA security. I don’t know the full extent of your required implementation, but thought if you’re looking for cross-platform encryption, would it be sufficient to create an encrypted hard disk on say a linux server, and share this as a windows device using SAMBA? This would been the data would be encrypted on your server, however there is nothing to stop your users copying the unencrypted files to their local machine, unless maybe you disable write access to all directories except the SAMBA share (say for their user home directory). Just an idea.

    Billy.

  33. John Hagtharp says:

    Couldn’t read this thread without feeling the need to correct Bruno’s misunderstanding about Truecrypt hidden volumes.

    The hidden volume is NOT an unpartitioned area of a disk. The way it works is:

    1. Create a truecrypt volume. (whole thing gets randomized)
    2. Create a filesystem on it.
    3. Stick some confidential looking files on it.
    4. Create a hidden truecrypt volume which will occupy the free space area within the filesystem you created in step 2.

    This hidden volume just looks like legitimate free space within the filesystem on the encrypted volume. It is randomized but so is the rest of the volume so no way to detect it is there.

    I can’t comment on other aspects of how secure truecrypt is.

  34. Msquared says:

    If you really want to hide data, and even make it plausibly deniable, you need something like stegfs. Unfortunately, that project has suffered due to lack of time for the developers to continue it.

    Details:

    http://www.mcdonald.org.uk/StegFS/

    http://stegfs.sourceforge.net/

  35. wev says:

    I spent 15 minutes typing an intelligent reply which got borkes with the message “your token has expired, please reload page”

    As a result I have nothing to contribute to this page.

  36. TAMA says:

    Run TRUECRYPT Easily On FEDORA – I HAVE THIS PATCH! Visit my blog here http://worldoftama.blogspot.com/. Download the installers and runtruecrypt file and do as directed. BINGO! u have it! http://worldoftama.blogspot.com/

  37. Tech, How to, Software Reviews, Linux, Dog, Make Money Online with AhTim says:

    Free Data Encryption Tool

    I have showed you the way to protect files and folders with Folder Protector 5.0. Have you take action to protect your confidential files and folders? Well, its all depends on your needs. But I highly recommend you to protect them or at least encrypt t…

  38. venkat says:

    I am using fedora core 2. I want to enable file system encryption. How can i acheive this

  39. Un disco USB cifrato con Fedora Core 6 « ACM Sistemi ~ How to Linux, Mac, Windows says:

    [...] L’articolo di RedHat Magazine che ha reso possibile questo documento:http://www.redhatmagazine.com/2007/01/18/disk-encryption-in-fedora-past-present-and-future/. [...]