Thu 02 of Sep, 2010 [15:28 UTC]  
Menu

EncryptExistingDevice

How to encrypt an existing device
edit print PDF
Português Brasileiro
I have tested this with LVM2 devices containing nothing important, it worked for me but you are advised to have current working backups if the data matters to you... you have been warned exclaim

In the following example we convert /dev/hda3 to use dm-crypt as the device /dev/mapper/hda3-aes

  • Make sure you have compiled the kernel the right way
    • Cryptographic options -> corresponding cipher
    • Device Drivers -> Multi-device support (RAID and LVM) -> Device mapper support -> Crypt target support
  • Make sure you have the device-mapper package installed
  • Unmount the device to be converted: umount /dev/hda3
  • Reduce the size of the partition (e.g. resize2fs /dev/hda3 8GB), to leave some free space (at least a few MBs) near the end.
  • Optional: fsck the device (to be sure there are no errors to start with): fsck /dev/hda3
  • Setup the new dm-crypt device: cryptsetup -y -c aes -s 256 create hda3-aes /dev/hda3 (enter the passphrase twice)
  • Start up the convertion process: dd if=/dev/hda3 of=/dev/mapper/hda3-aes bs=4k
  • Check the command twice as this will overwrite the contents of devices involved
__Warning: Interrupting this process will leave your device in an unusuable state.
Large devices should only be encrypted on systems equipped with a UPS. Additionally the process should be executed in a detached terminal via GNU Screen (eg. screen -L -d -m dd if=/dev/hda3 of=/dev/mapper/hda3-aes bs=4k). Further, some mechanism for logging should be used to monitor the last block written to the device. iostat is an excellent utility for this. The following script can be used:

#crypt_logger
#!/bin/sh
iostat dm-0 > encryption_log
cat encryption_log

  • Change the permissions on the script: chmod u+x crypt_logger
  • Start the logging process: screen -d -m watch -n 1 ./crypt_logger
  • If the process is aborted it is important to know the last block that was well written essay writing, in order to continue/reverse the process. In the event of a power failure the log file can be several seconds behind the actual encryption process. The process should be restarted at the next block, however it should be understood that several blocks will be encrypted twice, making them unusable. This method at least limits the damage of a power failure to a few seconds of encryption, as oppose to a catastrophic failure of the entire drive.
  • This could take some time. My test conversions (2Gb) took about 10 minutes on a dual P3 1Ghz. On a 2.6.24-3 kernel and a 1GHz Athlon processor, my system converted a 2TB RAID-5 array at a rate of 50GB/hour (lasting nearly 2 days).
  • Once the conversion has finished fsck the new device again: fsck /dev/mapper/hda3-aes
  • Mount /dev/mapper/hda3-aes where /dev/hda3 would normally have been mounted: mount /dev/mapper/hda3-aes /mnt/hda3

This can be used in reverse to move a device from being encrypted to be plain.

In addition you can use this with 2 different mappings to re-encrypt the device with either a new passphrase or with different options including cipher and key size, for detailed instructions see ChangePasswordtexttext



Help = Ajuda





Created by: night-shade last modification: Wednesday 01 of September, 2010 [19:38:33 UTC] by Anonymous


Posted messages

Top Hide all
author message
This is not safe!!!
on: Fri 04 of Jun, 2004 [06:40 UTC] score: 0.00
It is relatively easy to recover data from a hard disk, which has been overwritten, using special hardware. The partition must be wiped (repeatedly overwritten), before an encrypted file system is set up, unless there is nothing interesing on it. Even then, it may well be possible to recover the data. The only way to reliably destroy the unencrypted data is to physically destroy the hard disk.

Debian has the package "wipe".

http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html
http://sourceforge.net/projects/wipe


author message
I'ts even worse
on: Fri 04 of Jun, 2004 [06:47 UTC] score: 0.00
It's also possible to recover the unprotected encryption keys from the RAM chips, days after the power has been turned off.

Again, see
http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html



Page: 1/1
1