Linux SWAP and cryptloop / dm-crypt
- Linux SWAP and cryptloop / dm-crypt
This here creates a SWAP with a different, random key each time Linux is booted. This is good, as you do not need to enter a passphrase ever. But this makes suspend-to-disk (hibernation mode) impossible. You probably can still send the computer into standy mode, as the key for the SWAP file then is held in RAM. But as soon as you switch off the computer there is no way back - the password to SWAP is lost and the data there (which contains the hibernation information) cannot be decrypted again by your machine. So it is not able to resume from hibernation. All you can do is to reboot and loose the hibernation state. This probably is a crash recovery.
Encrypt Linux SWAP on Debian Squeeze
apt-get install cryptsetup
Edit the configurationCreate partition / devices for SWAP as usual. However do not format them as SWAP. Instead: For each Nth /path/to/SWAP-N you want to add following line to /etc/crypttab:
The encrypted device then will show up as /dev/mapper/swapN Then add the N swaps to /etc/fstab, here is the line for each one:
swapN /path/to/SWAP-N /dev/urandom swap
/dev/mapper/swapN none swap sw 0 0
ActivateNow do a
If the swaps are not already active, you need a
You can see the result with
Converting an old swap into cryptBE EXTREMELY CAREFULLY, YOU CAN DESTROY ALL YOUR DATA WITHIN THE FRACTION OF A SECOND if you have a typo!
Rename all lines for swap devices from /the/old/pathN to /dev/mapper/swapN. If you have an UUID there, then replace it with /dev/mapper/swapN, too. It is not possible to use UUID here as SWAP will be re-created on each boot.
If you are puzzled which device is using the UUID, try /dev/disk/by-uuid/ or the command blkid /path/to/drive, this way you can check if you really have the right path before continuing.Now for each /the/old/pathN clean the old contents:
The bs of roughly 1 MB often speeds up the process, for example on my Netbook without I get a write speed of 13 MB and 0% idle CPU, with it I get 70 MB/s and 20% idle. Note that this wipes the unencrypted disk. There is not much difference if you wipe the encrypted disk before swap is activated, except for the higher CPU load. Then add these swapN to /etc/crypttab again:
dd if=/dev/zero bs=1024000 of=/the/old/pathN
swapN /the/old/pathN /dev/urandom swap
dmsetup -C info
Which encryption algorithm to use?This is more an academic question. You can stay at the default. Even that the default mode is "a little bit weak" from a Cryptographers point of view, this is not a problem here. Only if you need more protection, then you need to switch the encryption mode. However in that case you certainly want to only encrypt your SWAP, right? So if you need a higher level of protection, you have to create an encrypted system. Normal people can live with the default modes. Even in the case of encrypted LVM. You only need to worry about such details if you really have a higher demand for a very good protection, a protection level only encrypted SWAP cannot give you.
- Perhaps ee github.com/hilbix/cryptspeed to test the speed of algorithms on your platform
Why?I do not need encryption to protect me against the Government. But I need encryption. Here is why: Harddrives fail. They fail unpredictably. And harddrives have warranty. The problem is, I cannot take any risks. I have sensitive data (often not even mine, it is from customers) on my disks. Can I safely hand them out to claim warranty? The answer is no, I cannot. If you have sensitive data, you cannot let repair your harddrive, as it is likely that you get a replacement unit, the original unit then perhaps is repaired and handed out to somebody else. This one then perhaps can get hold on passwords stored on the drive. Nope, I cannot take this risk. Hence the need for encryption in a way that nobody else can revert it in case the drive fails. If you think you do not need that deep protection, still think about passwords. Passwords are ususally stored encrypted, right? Wrong. They are stored as-is within RAM, as you are unable to enter them encrypted. If that RAM is swapped out to harddisk, it is unencrypted. So you still need crypt, at least for the SWAP drive. So to be on the safe side, always encrypt the SWAP.
I have not found a way to allow Windows to encrypt the Pagefile only, like presented here for Linux SWAP. This is why I either use TrueCrypt or BitLocker on the drives. Note that my setup is such that it uses keyfiles from USB. Truecrypt can be used with a boot-CD or Yubikey, too. This way the machine still is able to do unattended boots. But if something fails, I remove the USB Thumbdrive, and all data is locked. The data on the USB is printed and copied to several places, such that it can be recovered. It does not need to be kept secure, as it is not to protect against somebody else, it is only there to render the data unusable in case you need repair of a broken disk.
Some words about data erasureSome people tell you, that overwriting data with 0 bytes is not enough. They say, you must apply a NIST algorithm to securely erase the data. Please come on! What we are doing here? Are we a supernational intelligence service which can spend millions of dollar just to recover some bytes from a disk drive, or are we living in a real world? Nobody will apply such a high monetary effort to recover data from you, risking a complete loss in case nothing is found! Current data recovery companies offering professional service are incapable to restore a drive which was overwritten by 00 bytes, even when it only was done with a single pass. If they cannot, this protection level certainly is enough for nearly everybody. The problem with the erasure lies deeper and this is, sometimes, that data recovery experts can - randomly - recover some data from a harddrive. It is because of the self healing capabilities of a drive. When a sector becomes weak, it is remapped. The old data is not overwritten. So if you overwrite the data, the remapped sector becomes overwritten, and the data at the previous location never will be touched again. This certainly is a problem, but nothing can help, except destroying the drive. That is exactly what we are not going to do. But even the safest NIST algorithm is incapable to erase those left over (and hidden) data. This is why it is so important to make sure, all sensitive data on a drive is encrypted, as else erasure of this information becomes very difficult and expensive. So overwriting with 00 is certainly enough when changing from unencrypted SWAP to encrypted SWAP.
Modern drives are so densely packed with data, that there is no information leak on the boundary of the magnetic information. As there is simply no boundary left. Right, you can recover data from there. Single bits or even some byte parts. But not complete sectors. Only stray byte clusters with some highest probability rating can be found. However the selection of what is found is somewhat biased, as you can only find it if you look for it. So to put it together, writing 00 bytes on the drive erases it good enough for the future.