A few weeks ago I published a small HOWTO for using loop-aes to encrypt your hard drive, usb thumb drive etc.
As I have bought a new 300 GB external USB disk drive on Friday, I have tried something new this time: disk encryption using dm-crypt / LUKS. It has been suggested to me multiple times that dm-crypt is superior to loop-aes, however I didn't get a real reason. Yes, it doesn't require any kernel patches and is easier to setup. But has any serious cryptographer looked at it sharply, yet? Did it withhold his eye contact?
Anyways, here's how I encrypted my 300 GB drive. I largely followed the guide at the EncryptedDeviceUsingLUKS wiki page...
badblocks -c 10240 -s -w -t random -v /dev/sdb/dev/sdb with whatever is correct on your system. If you're really paranoid, and are willing to wait one or two days, do this:dd if=/dev/urandom of=/dev/sdb
apt-get install cryptsetup hashalotcfdisk /dev/sdb/dev/sdb1.
cryptsetup --verbose --verify-passphrase luksFormat /dev/sdb1/dev/mapper/samsung300gb device:cryptsetup luksOpen /dev/sdb1 samsung300gb
mkfs.ext3 -j -m 1 -O dir_index,filetype,sparse_super /dev/mapper/samsung300gbmkdir /mnt/samsung300gbmount /dev/mapper/samsung300gb /mnt/samsung300gb/mnt/samsung300gb will be encrypted transparently.
umount /mnt/samsung300gbcryptsetup luksClose /dev/mapper/samsung300gb
After unmounting, nobody will be able to see your data without knowing the correct passphrase. Drive is stolen? No problem. Drive is broken, and you want to send it in for repair without the guys there poking in your data? No problem. You leave the USB drive at home and some jerk breaks into your house, steals your drive, rapes your wife, and kills your kids? No problem. Well, sort of, but you get the idea ;-)
There's more things you can do, thanks to LUKS: have multiple passphrases which unlock your data, change/add/remove passphrases as you see fit, etc.
Comments?
Update 2006-04-17: You have to use cryptsetup from unstable if you want LUKS support. cryptsetup in testing does not support this (thanks Ariel).
Comments
yast
How I can mount my home directory encrypted by yast in opensuse without yast? (my system cann't start!, now I install kubuntu)
I have:
/home/user
/home/user.img (2Gb)
/home/user.key (288b)
?
data corruption
Q: what if HDD get some bad blocks/sectors, or any other corruption after being encrypted? How widespread the error will be on the unencrypted view? Will all my data lost or just a file or two?
Thx, Dolfy
corruption
Good question, I was planning on testing just that on some test image. I guess only some blocks will be affected, but it probably also depends on the type of cipher and mode you use.
If anybody else does tests, please leave a comment and let us know.
Thanks
Thanks for this howto, I have aplied it to an external harddrive in Fedora 10 without any problems.
Anonymous
dd if=/dev/urandom of=/dev/sdb
is VERY slow.
I use this command:
shred -n 1 /dev/sdb
This work 100x faster.
Try ATA over ethernet
If you are installing on a slow laptop and have a fast machine on the local network, try ATA over ethernet:
ATA Over Ethernet On Debian
Here it depends on the speed of my 100Mb ethernet. I run the urandom on a quad core AMD64 machine and fill the disk partition on a Pentium-M 1.6 GHz laptop.
Hans
I find it strange, because
I find it strange, because shred is by default using exactly the same /dev/urandom, which is almost sure to be a bottleneck. Actually, in my case, there's really no noticeable difference. Maybe if you tell dd to copy more blocks at once, it will go faster?
e.g.
dd if=/dev/urandom of=/dev/sdb bs=10240
(10MiB at once)
or wipe /dev/sdb
or
wipe /dev/sdb
HOWTO do this without formatting the drive?
Thanks for the tutorial...it was the easiest I have seen yet!
But, I want to do this without formatting my drive. Can it be done as easily? I have seen tutorials but they seem a bit vague, so when I found your site I thought I'd ask you as you seem to be in the know...
I installed Debian Etch on a server and I have an external firewire WD MyBook 320GB attached to it. Debian is using dmcrypt and LVM at the moment for all partitions except /boot so I think I have everything on the server to be able to do this.
I saw somewhere on an Ubuntu forum that this could be accomplished by using dd to copy the contents of the drive back to itself by going via the mapper device and it was basically two commands to run, one to setup the mapper and the other to run dd with 'if' as the /dev/sda1 and 'of' as the mapper device. Does this seem safe?
dm-crypt
Hi, first of all, the latest Debian installer already has an option to automatically setup all of this stuff for you, no command line hacking needed anymore.
I'm not sure I entirely understand what you're trying to do (or how the proposed dd hack is supposed to work). I don't know any easy way to make a dm-crypted disk out of an unencrypted disk. The only way is to make backups on some other disk/medium, install a fresh Debian with dm-crypt (via installer or manually) and then copy the backups (your data) on the new, encrypted disk.
HTH, Uwe.
HOWTO encrypt existing partition with dd
I found the link (not ubuntuforums) that explains how to do this on http://www.richardneill.org/a22p-mdk11-0.php#encrypt2 ...
[5] An aside on dm-crypt/cryptsetup
Actually, dm-crypt is the most promising way, but it involves too much fighting with Mandrake's init-scripts. Also, diskdrake doesn't understand, and I would guess that drakupdate_fstab won't. There is no need to use it (loop-AES is fine), but since I attempted it, here are some brief notes.
Here is how to Encrypt an existing device using the device-mapper.
init 3
umount /home
modprobe dm-crypt
cryptsetup -yv -c aes -s 256 create hda9-aes /dev/hda9 #hda9 = /home. Passphrase = usually 256 = max key size.
dd if=/dev/hda9 of=/dev/mapper/hda9-aes bs=64k #this should encrypt the data in place.
reiserfsck /dev/mapper/hda9-aes #check the filesystem.
off topic
this is not the LUKS way
it's just the normal crypt_dm way, which cannot change key or have more than 1 key
It all went to h*ll
Hi Uwe,
I decided to follow your guide after having mailed the debian-users list and been advised against the dd copy method :)
I followed your guide to the letter and it seemed to work perfectly, but I now have some serious issues with weird behaviour and serious performance issues.
My setup is:
Acer Aspire AMD Turion ML-28 1.6GHz 512MB running Etch 4.0r1 fully encrypted with LVM created using the guided partitioner.
Western Digital Firewire400 MyBook 320GB formatted as per your guide.
issues:
1. performance is at 50% normal compared to before encrypting the external drive. SCP from another ethernet connected laptop to MyBook gives very varying speeds from 2.9MB/s to 7.2MB/s instead of normal constant 11.5MB/s without encryption. Read performance is just as bad over wireless at 1.5MB/s instead of 2.5MB/s.
2. SCP constantly "stalls" (in the CLI it says -Stalled-) quite often so that copies take much much longer than they should *at that transfer rate*. I have never seen scp stall before.
3. If I copy a file from the host laptop to the MyBook using cp from terminal then CPU goes to over 90% with kjournald and kcryptd/0 using the CPU. If I time the copy with /usr/bin/time then after copying it only reports having used ~2% CPU!?
4. If I move the focus to another window other than the terminal window whilst copying, then CPU drops to zero, disk activity stops and "nothing happens" until I re-focus on that terminal window. Same bahaviour if I shut laptop lid (its set to blank screen) or if screensaver becomes active.
Just to re-iterate; I installed Etch last week, standard net install with laptop, base and desktop options. Other than that, no changes from default install. I have since enabled CPU frequency stepping as it did not work OOTB. Everything else is from the standard install.
I would really appreciate if you could give me some tips or ideas as to what the issue could be and whether this performance hit is normal.
--andrew
This is probably better
This is probably better posted in debian-user, but here are some ideas. The problems seem more network-related than dm-crypt related to me. The slowness may have to do with the CPU frequency scaling, make sure you don't put it into "powersave" mode or similar (where the slowest frequency will be used).
I use dm-crypt on quite a number of PC and I don't see any noticable slow-down.
dmcrypt issues with Etch standard kernel
I fixed the problem by compiling and running kernel 2.6.23.9. disk activity is now fast and constant but CPU usage is still high. Seems like kernel supplied with Etch is not suitable for usage with dmcrypt.
Of course CPU usage is high,
Of course CPU usage is high, the CPU is being used to run the encryption and decryption algorithms. When combined with SCP, it has to do the usual SSH encryption/decryption, plus the LUKS encryption/decryption. If you want that done fast, it needs clock cycles. Duuhhh!!
To do what so that the content can be read out in other machines
I have a question that if I wanna the contents on an encrypted partition can be read out on another computer, what should I do? Just use cryptsetup to build another mapping device and mount it?
Yes, wipe would be another
Yes, wipe would be another option. Or shred. I'll try to find a comparison of all these tools and their effectiveness in regard to "real" random garbage and their speed.
cryptsetup on another computer
I'm not sure that this is what you're looking for, but yes, you can rip out the hard drive from computer A, put it in computer B and use cryptsetup (either from the hard drive you just moved, or from another drive on computer B or from a live CD in computer B) to mount the encrypted volume (given you know the passphrase, of course).
HTH, Uwe.
Security of LUKS vs. loop-AES
Although I'm not a cryptographer either, if the loop-aes image resides on a filesystem on which journaling has been enabled (pretty common these days), that can give attackers information on how the encrypted file system has changed over time. This might only be relevant for weak cipher feedback modes. From http://en.wikipedia.org/wiki/Disk_encryption_theory:
----
Despite the fact that it is possible in practice to use the counter (CTR) mode with a single IV per volume, such uses are insecure if an adversary is able to gather several encrypted versions of the same sector (e.g., snapshots taken at different times).
----
luksClose
where you have cryptsetup luksClose /dev/mapper/<name>, I found that did not work, I had to use cryptsetup luksClose <name> instead.
Ciao
luksClose
That's strange, both should work. I just tested both variants and both work fine. This is cryptsetup-luks 1.0.5.
Uwe.
thanks!
Works like a charm. Thank you!
OTP
How to add one-time password support to an encrypted device?
luks, xfs, hardware raid..... issue
When I try to format xfs partitions above 2-3gb my opteron experiences heavy io wait; the mkfs.xfs fails, and I receive the following....
"mkfs.xfs: libxfs_device_zero write failed: Input/output error"
When I format partitions below 2-3gb, there is no problem whatsoever. I can mkfs.xfs on a +2-3GB non-luks formated partition without a problem. I can format above 2-3gb luks partitions using ext3 without a problem. I like xfs, I like luks, but why don't they like each other? ...any thoughts?
(the xfs gurus suggested I pose my question to the luks gurus, due to the fact that xfs formatting works on the same partitions without luks)
Thanks man, Great article
Thanks man, Great article
mounting as normal user
Hi
Are you able to open (luksOpen) and/or mount as a normal user?
I ran this command as root
cryptsetup luksOpen /dev/sda1 sda1
and mounted my partition as normal user but then, the partition becomes "READONLY". Only root can write onto it...
My /etc/fstab:
/dev/mapper/sda1 /mnt/sda1 ext3 noauto,rw,users,nosuid,exec 0 0
Any suggestions...
Try changing the permissions
Try changing the permissions or ownership of the mount directory (ie. /mnt/sda1). Eg, change owner to the user who will use it, or change permissions to 777.
UPDATE?
Hello, Uwe!
According to this:
http://packages.debian.org/testing/admin/cryptsetup
LUKS is supported now in 'testing'.
~Cheers~
Enable the following options in your kernel??????
> Enable the following options in your kernel:
As more & more Linux users; not programmers nor hobbyists--but users, like myself, install Linux using a single disk: MEPIS, Knoppix or Ubuntu; all of which are Debian based. Many of us have absolutely no idea how to make kernel changes. Can you point to a reference that explains this part from the absolute ground-up?
Thanks,
Lance
Derek
You have a very nice site and good guestbook, thank you.
Then wait until distributions pick up the technology
Fedore Core 5 seems to include Luks support already, with user-friendly GUI tools.
Take cryptsetup from unstable
In the item 4, it should be noted that currently Luks support is only in the cryptsetup package in unstable, not in the testing one...
backports
You may also use :
deb http://www.backports.org/debian/ sarge-backports main
in your /etc/apt/sources.list if you want to have Luks support in the cryptsetup package in stable.
P.S. thanks for your mini how-to !
Thanks, I have clarified
Thanks, I have clarified this in the article.
Tyson
keep up the good work
Seems unsafe
Unless I remember incorrectly, "badblocks -t random" will generate one random pattern (one block, default 1k)....and write that repeatedly to the drive.
This defeats the purpose of the random write. Instead, a dd if=/dev/urandom of=/dev/sdb should be performed (which will take several hours or even days depending on disk size and processor speed)
badblocks and random numbers
Yes, the badblocks randomizing method should not be considered very secure, those are no "real" random numbers. But I guess it's better than nothing (i.e., better than a disk full of zeros).
dd with /dev/urandom takes 2-3 days on my Pentium M 1.6 GHz and a 300 GB USB hard drive. And the CPU load is at 100% constantly, both my laptop and the drive get quite hot...
Not better than zero
Well...the problem is that it would be just as easy to distinguish unused blocks.
Find any commonly recurring block, and there you go...
A better, asm-optimized solution would be to setup a temporary cryptmount (for example with a random key from /dev/random and using aes256 cipher) and dd /dev/zero to that.
Provided that aes is not a weak cipher, which seems unlikely, the output should be indistinguishable from random data, and the operation should be quite a bit faster than urandom.
How about using wipe
I remember there are specialized apps for secure deletion of a drive.
E.g. wipe. Maybe these could help here? They might contain a fast way to generate useful random patterns.
make sure you understand what is happening
before you use a tool such as shred!!!!! You cannot leave the drive blank (all zeroes). If you use a tool that zeroes out the drive, while the erased data will be obscured at the least, your new data will be very vulnerable. You have to have random data (or as close as you can get within your time constraints) when setting up the partition, zeroes are not random! Go with the badblocks, or /dev/urandom methods commonly used.
wipe
Yes, wipe would be another option. Or shred. I'll try to find a comparison of all these tools and their effectiveness in regard to "real" random garbage and their speed.
If you know such a study (no ad hoc tests please, only scientific papers from some serious cryptographer), please let me know.
Uwe.
This is the paper that
This is the paper that inspired wipe:
Peter Gutmann: Secure Deletion of Data from Magnetic and Solid-State Memory
http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html
In this (1996) paper, Gutmann suggests a 35-pass wiping technique that makes it much harder for a well-equipped adversary to read data off the disk. However, the epilogue notes the following:
In the time since this paper was published, some people have treated the 35-pass overwrite technique described in it more as a kind of voodoo incantation to banish evil spirits than the result of a technical analysis of drive encoding techniques. As a result, they advocate applying the voodoo to PRML and EPRML drives even though it will have no more effect than a simple scrubbing with random data. In fact performing the full 35-pass overwrite is pointless for any drive since it targets a blend of scenarios involving all types of (normally-used) encoding technology, which covers everything back to 30+-year-old MFM methods (if you don't understand that statement, re-read the paper). If you're using a drive which uses encoding technology X, you only need to perform the passes specific to X, and you never need to perform all 35 passes. For any modern PRML/EPRML drive, a few passes of random scrubbing is the best you can do. As the paper says, "A good scrubbing with random data will do about as well as can be expected". This was true in 1996, and is still true now.
Looking at this from the other point of view, with the ever-increasing data density on disk platters and a corresponding reduction in feature size and use of exotic techniques to record data on the medium, it's unlikely that anything can be recovered from any recent drive except perhaps one or two levels via basic error-cancelling techniques. In particular the the drives in use at the time that this paper was originally written have mostly fallen out of use, so the methods that applied specifically to the older, lower-density technology don't apply any more. Conversely, with modern high-density drives, even if you've got 10KB of sensitive data on a drive and can't erase it with 100% certainty, the chances of an adversary being able to find the erased traces of that 10KB in 80GB of other erased traces are close to zero.
So for practical purposes, a couple passes over the drive with
dd if=/dev/urandomis probably the best that can be hoped for.Why use multiple passes at all?
I also can't imagine how it would be possible to recover data from a disk that was (physically) overwritten (with a random pattern). Not even for these old MFM and RLL drives which Gutmann is talking about in his article from 1996. Just imagine you know that a 1 (or 0) is stored somewhere and you would be able to detect the kind of bit that was stored before, what does it tell you? You would not know whether this previous bit was stored by the erase process or by any of the other (hundreds or thousands) of storage processes applied to this bit. So why waste time with multiple overwrite passes if even one would be sufficient?
re: multiple passes
The reason behind multiple passes has to do with the physical properties of the storage medium.
On a hard drive you have physical platters that are coated in a material that holds information through polarization.
For most intents and purposes the information stored is a true binary data (N or S polarization), but because the density is not 1 bit per molecule, there is a possibility that a particular bit may only be partially polarized, meaning that some of the field may actually be polarized with the old data, meaning that should someone either use specialized forensic software or physically dissect the drive, it may be possible to recover the original information. Each new pass of random information reduces this possibility of recovering the information by compounding the magnetic 'echos' to the point that, which echo is valid, becomes nearly impossible to determine. How many passes are taken should be directly related to the sensitivity of the information that was in that area of the disk being wiped. The multiple pass approach normally includes either all 0's and/or all 1's as one or more of the passes, before or mixed in with the random passes (not the last pass), just to ensure that every bit changes polarity at least once and in such a way to make it more difficult to recover the information.
Anything beyond 26 passes is just overkill, and unless the information is TS-SCI, even 26 passes is going to be a bit excessive.
Many Thanks
Good, now I can do this and shut up my Vista
bigoted friends.
The only sticking point for me is the kernel option related stuff but there's no time like the present to learn how.
Thanks again!
Citizen Jimserac
Using Debian Unstable
Encrypted Filesystem
Worked beautifully.
There were a few other things I had to install
before being able to do my make xconfig
but no kernel options needed to be
set up as they were already at the
correct settings.
I've been dreaming about having this ever
since I read "Cryptonomicon" years ago
and now I have it. The whole thing took
about 20 minutes to set up.
Its fast too.
Thanks
Citizen Jimserac
Tutorial for encrypting a working disk with remote access only?
Newbie here that has been looking for a 'complete' tutorial how to encrypt a drive that:
1. Only have remote access to, login is done via SSH, no GUI.
2. Already existing programs and users on the site
3. Just want to encrypt sensitive areas not entire disk as told that to do would make it almost impossible for a newbie to do and still be able to login remotely via SSH.
Sensitive areas?:
/home/...,
/jail/glftpd/...
and logs, etc, don't really know?
I've been told cryptsetup is great for this and that one would need to make partitions, containers, etc.. completely lost and scared to try anything without a complete tutorial including the partition parts.
Any chance of this? :D
Thank you!