The fight against piracy is gaining new momentum, right holders and government agencies are redoubling their efforts in this difficult matter. I suppose each of us thought about how to protect personal files from encroachment by "unexpected guests", and simply too inquisitive persons.
We will encrypt disks standard means Ubuntu, and the encryption key, like the /boot partition, will be placed on a removable drive. But why encrypt the root partition? After all, you can only encrypt /home? There are several reasons for this. The first one is based on configuration files some information can be extracted from /etc, even if it is not sensitive data. The second is that if suddenly the contents of the disk become interested, you can always say that everything happened and that the disk was already full of pseudo-random data. So, what is needed for this?
We will use AES as a disk encryption algorithm, since it is accepted as a standard and crypto-resistant, and cryptsetup / LUKS as a means. To be able to add free space on top of the encrypted volume, let's use logical volumes (LVM).
After booting from the LiveCD, you need to prepare a flash drive: create a second partition on it, where /boot and the encryption key will be placed. By creating the /boot partition with the ext2 file system as the second, we kill two birds with one stone - the first partition will be visible in all systems, and data can be stored on it, and the second one from Windows cannot be seen so easily, which adds inconvenience to the curious. For partitioning, I used gparted, but no one bothers you to use, for example, fdisk. After that, you need to mount the newly created partition and generate key file:
Why read one byte at a time? The point is that the pool random numbers in the kernel is relatively small and does not always contain enough random data, so the mouse was moved randomly during generation.
Let's see what this command does. The first key specifies the type of hash function to be used to hash the master key. The second key specifies the encryption algorithm and type. I will dwell on this in a little more detail. What is CBC? As you know, AES is a block cipher that operates in blocks of 128, 192 or 256 bits. But, as a rule, much larger amounts of information are encrypted. And the problem arises - how to encrypt so that a non-random distribution is not visible, from which a cryptanalyst can extract information. Smart people solved it this way: the first block contains IV - a random set of bits. And each subsequent block of open data is XORed with the previous block of already encrypted data. Everything seems to be fine, but in the case of disk encryption, such a scheme, for obvious reasons, is not applicable (you won’t wait 10–20 minutes each time until the system decrypts the section you need?). In LUKS, ESSIV is used to solve the problem of random access to information - relatively small blocks of data are encrypted (sector by sector), and the initialization vector is generated based on the sector number and key hash. Such a scheme also protects against some crypto-attacks. In particular, this is why I use LUKS. Confirming your intentions after launch previous team, create a LUKS device mapping:
# cryptsetup -d=/mnt/boot/key.bin luksOpen /dev/sdd cryptodisk |
The first stage of preparation is completed - now the cryptodisk device has appeared in the /dev/mapper directory, which can be treated like a regular disk.
In principle, now you can install Ubuntu on the newly created cryptodisk, but, as I already wrote, in order to be able to increase the space, it is better to create an LVM volume on top of it, which we will do. Let's initialize the physical volume and create a volume group:
Now you can format them into file systems. You are free to choose yourself, but I used the good old ext4 both for the root volume and for vg-home - in my opinion, we have already cheated too much to use newer file systems:
We only need to install Ubuntu on an unencrypted partition/disk and move it to an encrypted one.
Now we put on unencrypted Ubuntu disk- do the configuration to your liking, except for the placement of /boot and bootloader. They must be placed on a flash drive, where you created the appropriate section in advance. After that, we boot from the USB flash drive to check if everything has risen correctly, install the lvm2 and cryptsetup packages using apt-get - they were removed automatically after Ubuntu installations- and add/change the lines /etc/fstab. You should get something similar (with the exception of lines with pseudo-file systems, which, however, in modern systems No):
/etc/fstab UUID=dd7ca139-074a-4b1b-a116-3a42feab7459/boot ext2 defaults 0 2 /dev/mapper/vg-root/ext4 errors=remount-ro 0 1 /dev/mapper/vg-home/home ext4 defaults 0 1 / dev / mapper / vg - swap none swap sw 0 0 |
We mount the /boot partition by UUID so that when adding new disks there is no confusion with their names. Now we go to the /etc/crypttab file, we have it with the following content:
Let's create a script in order not to mount the USB flash drive once again:
Copy the key and cryptsetup
cp / boot / key .bin $ ( DESTDIR ) / etc / crypto copy_exec / sbin / cryptsetup / sbin |
And the actual script for connecting the cryptodisk (runs during initrd boot):
/etc/initramfs-tools/scripts/local-top/cryptokeys. . . modprobe - b dm_crypt while ! /sbin/cryptsetup -d=/etc/crypto/key.bin luksOpen /dev/disk/by-uuid/c34e4c91-1fa1-4802-88ca-9c3be5c99097 cryptodisk ; do echo "Try again..." done |
The while loop is necessary if you later add volume unlocking with a password. Both scripts must be executable, otherwise the next command will not see them and will create a standard image. Now you can issue the initrd update command:
# update initrd -u -k all -v |
We almost forgot about the bootloader config. There are two ways to edit it: one is simple but wrong - direct editing of the /boot/grub/grub.cfg file, the second is also simple, but this time correct. The incorrectness of the first method is that with each kernel update, the config is overwritten using scripts from /etc/grub.d/. We will go the other way - we will add a script that will generate the correct lines in the real Grab config. However, there is one “but” - when updating the kernel, you will either have to change it every time, or stay on the old one (the latter, in my opinion, is preferable - see sidebar). This is what his lines look like:
/etc/grub .d/40_custom menuentry "Ubuntu crypto" ( recordfail = 1 if [ - n $ ( have_grubenv ) ] ; then save_env recordfail ; fi set quiet = 1 insmod part_msdos insmod ext2 insmod gzio |
UUID is taken from a pre-recorded file
search -- no - floppy -- fs - uuid -- set = root dd7ca139 - 074a - 4b1b - a116 - 3a42feab7459 |
The /boot partition is considered the root partition for Grub, so the paths to the kernel and the initrd image are relative to it.
Optionally, you can turn off the menu items you do not need. To do this, simply remove the execute permission from all unnecessary scripts in /etc/grub.d/. Now you can update the main config:
After copying, you can try to boot from the flash drive - just select the Ubuntu crypto menu item. If everything went well, after a while you will see a login prompt. In that case, I can congratulate you - you are already working in an encrypted system.
Let's say you need to change the key - you compromised it or just created a change policy and want to strictly follow it. What is needed for this? First of all do backup volume header LUKS - if everything goes well, after changing the key you can destroy it. We do it, of course, on an unencrypted partition:
We look at the current keylots (the places in the header of the encrypted volume where the keys are stored - yes, there can be more than one) and remember the number of the active one (Enabled). Typically, this is zero.
TrueCrypt is no longer maintained, but dm-crypt and LUKS are a great open source option. source code, which allows you to encrypt and use encrypted data.
Data security has become one of the biggest concerns among internet users. News of data theft from websites has become very common, but protecting your data is not only the responsibility of websites, there is a lot that we, as end users, can do for our own security. For example, just a few examples are using strong passwords, encrypting the hard drives that are located on our computers, and using secure connections. In particular, hard disk encryption is in a good way security - it will not only protect you from any Trojans trying to steal your data over the network, but also from physical attacks.
In May of this year, development of the TrueCrypt application, a well-known open source tool for disk encryption, stopped. As many of you know, it was one of the very reliable tools for encrypting drives. It's sad to see a tool of this caliber disappear, but such is the greatness of the open source world that there are several other open source tools that can help you achieve security with disk encryption, which also have a lot of configuration settings. We will consider two of them - dm-crypt and LUKS - as TrueCrypt alternatives for the Linux platform. Let's start with a quick look at dm-crypt and then LUKS.
This is basic information about a device using LUKS, which indicates what encryption is used, the encryption mode, the hash algorithm, and other cryptographic data.
The name of the application dm-crypt is short for device mapper-crypt (encrypt when mapping a device). As the name suggests, it is based on a device mapping framework. Linux kernels, designed to map block devices to higher-level virtual block devices. When mapping devices, you can use several kernel features, such as dm-cache (creates hybrid volumes), dm-verity (designed to check the integrity of blocks, is part of Chrome OS) and also the very popular Docker. For cryptographic purposes, dm-crypt uses the Linux Kernel Crypto API framework.
So, to summarize, the dm-crypt application is a kernel-level encryption subsystem that offers transparent disk encryption: this means that the files are available immediately after the disk is mounted - there is no visible delay for the end user. To encrypt using dm-crypt you can simply specify one of the symmetric ciphers, the cipher mode, the key (any size allowed), the IV generation mode, and then create a new block device in /dev. Now, when writing to this device, encryption will occur, and when read, it will be decrypted. You can mount a filesystem on this device as usual, or you can use the dm-crypt device to create other constructs such as a RAID or LVM volume. The mapping table for dm-crypt is set as follows:
Here, the value of start-sector is typically 0, the value of size is the size of the device in sectors, and the target name is the name you want to give to the encrypted device. The target-mapping table consists of the following sections:
As we saw in the previous step, the dm-crypt application can encrypt/decrypt data on its own. But it has a few drawbacks - if you use dm-crypt directly, it won't create metadata on disk, and this can be a big problem if you want to ensure compatibility between different Linux distributions. Also, the dm-crypt application does not support the use of multiple keys, while in real life it is very important to use multiple keys.
It is for these reasons that the LUKS (Linux Unified Key Setup) methodology was born. LUKS is the standard for hard disk encryption in Linux, and standardization allows for compatibility across distributions. Multiple keys and passphrases are also supported. As part of this standardization, a LUKS header is added to the encrypted data, and this header contains all the information necessary for configuration. When there is such a header with data, then users can easily switch to any other distribution. The dm-crypt project currently recommends using LUKS as the preferred way to set up disk encryption. Let's look at how to install the cryptsetup utility and how to use it to create LUKS-based volumes.
The kernel-level functionality that is used in dm-crypt is already in all Linux distributions; we only need an interface to them. We will be using the cryptsetup utility, which allows you to create volumes using dm-crypt, the LUKS standard, and the good old TrueCrypt application. In order to install cryptsetup on Debian/Ubuntu distributions, you can use the following commands:
$ sudo apt-get update $ sudo apt-get install cryptsetup
The first command synchronizes rocket index files with the contents of their repositories: it gets information about latest versions all available packages. The second command will download and install the cryptsetup package on your computer. If you are using the RHEL/Fedora/CentOS distribution, you can use the yum command to install the cryptsetup utility.
$ yum install cryptsetup-luks
Now that the cryptsetup utility has been successfully installed, we need to create a target file that will hold the LUKS container. Although there are many ways to create such a file, a number of conditions must be met when creating it:
In creating a file that will satisfy the above conditions, the dd command can help us, although it will work relatively slowly. Just use it with the special device file /dev/random specified as input and the target file to be specified as output. An example command looks like this:
$ dd if=/dev/random of=/home/nitish/basefile bs=1M count=128
This will create a 128 MB file called basefile in the /home/nitish directory. However, please note that this command may take a long time to complete; in the system that our expert used, it took an hour.
After you have created the target file, you need to create a LUKS section in this file. This section serves as the base layer upon which all data encryption is built. In addition, the header of this section (LUKS header) contains all the information required for compatibility with other devices. To create a LUKS partition, use the cryptsetup command:
$ cryptsetup -y luksFormat /home/nitish/basefile
After you agree that the data inside the basefile will be permanently deleted, enter the passphrase, and then confirm it, the LUKS partition will be created. You can check this with the following file command:
$filebasefile
Please note that the phrase you enter here will be used to decrypt the data. It is very important to memorize it and store it in a safe place, because if you forget it, you will almost certainly lose all the data on the encrypted partition.
The LUKS container we created in the previous step is now available as a file. In our example, this is /home/nitish/basefile. The cryptsetup utility allows you to open a LUKS container as an independent device. To do this, first map the container file to the device name and then mount the device. The display command looks like this:
After you successfully enter passphrase created in the previous step, the LUKS container will be mapped to volume1. What actually happens is that the file is opened as a local loopback device, so that the rest of the system can now treat the file as if it were a real device.
The LUKS container file is now available on the system as a regular device. Before we can use it for normal operations, we must format it and create a file system on it. You can use any file system that is supported on your system. In my example, we used ext4 as it is the newest file system for Linux systems.
$ mkfs.ext4 -j /dev/mapper/volume1
Once the device has been successfully formatted, the next step is to mount it. You must first create a mount point, preferably in /mnt (common sense).
$ mkdir /mnt/files
Now we mount:
To cross-check, use the df –h command - you will see the device "/dev/mapper/volume1" at the end of the list of mounted devices. It can be seen that the LUKS header already occupies some space in the device.
Thanks to this step, you can now use a LUKS device with an ext4 filesystem. Just use this file storage device - everything you write to this device will be encrypted, and everything you read from it will be decrypted and shown to you.
We have followed several steps in order to achieve this result, and if you are not very clear on how it all works, you will most likely be confused about what needs to be done only once (required for installation), and that should be done regularly when using encryption. Let's consider the following scenario: you successfully completed all the steps above and then turned off your computer. The next day, when you start your computer, you are unable to find the mounted device - where did it go? To deal with all this, you need to keep in mind that after starting the system, you need to mount the LUKS container, and unmount it before stopping the computer.
To access the LUKS file, each time you turn on your computer, follow these steps, and then safely close the file before you turn off your computer:
Open the LUKS file (i.e. /home/nitish/basefile) and enter the password. The command looks like this:
$ cryptsetup luksOpen /home/nitish/basefile volume1
Once the file is open, mount it (if it doesn't mount automatically):
$ mount /dev/mapper/volume1 /mnt/files
Now you can use the mounted device as a regular disk and read from or write data to it.
Once done, unmount the device like this:
$ umount /mnt/files
After successfully unmounting, close the LUKS file:
$ cryptsetup luksClose volume1
Most loss of data stored in a LUKS container is due to corruption of the LUKS header or key slots. In addition to the fact that LUKS headers can be corrupted even due to accidental overwriting in header memory, in real conditions It is also possible that the hard drive will fail completely. The best way to protect against such problems is backup. Let's see what backup options are available.
To back up the LUKS header file, specify the luksHeaderBackup parameter in the command:
$ sudo cryptsetup luksHeaderBackup /home/nitish/basefile --header-backup-file /home/nitish/backupfile
Or, if you want to restore a file from a backup, specify the luksHeaderRestore parameter in the command:
$ sudo cryptsetup luksHeaderRestore /home/nitish/basefile --header-backup-file /home/nitish/backupfile
You can use the isLuks parameter to check for a LUKS header file and verify that the file you are dealing with corresponds to an actual LUKS device.
$ sudo cryptsetup -v isLuks /home/nitish/basefile
We've already seen how to back up LUKS header files, but backing up a LUKS header doesn't really protect against a total disk failure, so you need to back up the entire partition with the following cat command:
$ cat /home/nitish/basefile > basefile.img
There are a few other settings that can be useful when using dm-crypt LUKS encryption. Let's take a look at them.
To dump the LUKS header, the cryptsetup command has the luksDump option. It will allow you to take a snapshot of the LUKS header file of the device you are using. An example command looks like this:
$ cryptsetup luksDump /home/nitish/basefile
At the beginning of this article, we mentioned that LUKS supports multiple keys. Let's see this in action now by adding a new key slot ( note per.: key slot - turnkey place):
$ cryptsetup luksAddKey --Key-slot 1 /home/nitish/basefile
This command adds a key to key slot number 1, but only after you enter the current password (the key present in key slot 0). There are eight key slots in total, and you can decrypt data using any key. If you dump the header after adding the second key, you will see that the second key slot is occupied.
You can remove key slots like this:
$ cryptsetup luksRemoveKey /home/nitish/basefile
This will remove the key slot with the highest slot number. Be careful not to delete all slots or your data will be permanently lost.
: - Russian
Active page development completed
If there is something to add, then supplement the sections with new information. Our typos and errors in the article can be edited safely, there is no need to report this by mail, please observe styling this page and use section separators (grey lines of varying thickness).
Many people think that you do not need to encrypt your data. However, in everyday life, we often encounter such situations as “a flash drive was lost” or “a laptop was handed over for repair”, etc. If your data is encrypted, then you don’t have to worry about it at all: no one will publish it on the Internet, or use it in any other way.
Install the necessary components:
# apt-get install cryptsetup/dev/sda2. Let's enter the command:
# cryptsetup create sda2_crypt /dev/sda2This command will create an encrypted connection to our disk. In catalog /dev/mapper a new device will appear with the name we requested: /dev/mapper/sda2_crypt, accessing which we use encrypted disk access. In the case of LUKS, the name would be /dev/mapper/sda2_crypt
If there was already a file system on the disk and we would like to save data on it, then we need to encrypt them for their subsequent use:
# dd if=/dev/sda2 of=/dev/mapper/sda2_cryptIf a new disk is created on an empty partition, then you can format it:
# mkfs.ext3 /dev/mapper/sda2_cryptLater, you can mount this disk anywhere:
# mount /dev/mapper/sda2_crypt /path/to/mount/pointCheck data integrity (as usual, best used only in unmounted state):
# fsck.ext3 /dev/mapper/sda2_cryptAnd even decrypt back if we don't want to use encryption anymore:
# dd if=/dev/mapper/sda2_crypt of=/dev/sda2The above steps can be done according to the LUKS standard
We initialize the section:
cryptsetup luksFormat /dev/sda2We connect to the system:
cryptsetup luksOpen /dev/sda2 sda2_cryptFormatting:
mkfs.ext4 -v -L DATA /dev/mapper/sda2_cryptWe mount:
mount /dev/mapper/sda2_crypt /mnt/dataThe section can be manually disabled about the system
cryptsetup luksClose sda2_cryptThe file is used for this purpose. crypttab.
For our disk, write the following line into it:
nano /etc/crypttab # name mapper device key params/options # Standard syntax sda2_crypt /dev/sda2 none aes-cbc-plain:sha256 # and/or LUKS standard sda2_crypt /dev/sda2 none luksThe default is to encrypt with a password entered by the user. Thus, every time you boot your computer, the system will ask you every time for a password to connect each encrypted partition. Even if these sections are not registered in fstab.
If we want to mount manually, then add the option auto in the "Settings/Options" field.
Mounting an encrypted partition manually according to data from /etc/crypttab
cryptdisks_start msda2_cryptAnd shutdown with pre-mounted fs.
cryptdisks_stop sda2_cryptTo automatically mount the fs on the connected encrypted partition, add a line to /etc/fstab
/dev/mapper/sda2_crypt /mnt/data ext4 defaults 0 0The LUKS section supports 8 different keys, each of which fits into its own slot.
View the list of used keys
cryptsetup luksDump /dev/sda22 types of keys can be used in LUKS - key phrases and files.
You can add a keyword
cryptsetup luksAddKey /dev/sda2You can add a key file (2048 bit) and set access rights to it.
dd if=/dev/urandom of=/root/ext2.key bs=512 count=4 cryptsetup luksAddKey /dev/sda2 /root/ext2.key chmod 400 /root/sda2.key cryptsetup -d /root/sda2.key luksOpen /dev/sda2 sda2_cryptTo connect at startup by key, edit /etc/crypttab
nano /etc/crypttab sda2_crypt /dev/sda2 /root/sda2.key luksYou can remove a passphrase or key from a section
cryptsetup luksKillSlot /dev/sda2 1No one is safe from problems and sometimes you need to access an encrypted partition from an emergency LiveCD disk.
We boot, connect the partition to the system and mount the fs:
cryptsetup luksOpen /dev/sda2 sda2_crypt mount -t ext4 /dev/mapper/sda2_crypt /mnt/backupAfter work, unmount the fs and disconnect the encrypted partition from the system
umount /mnt/backup cryptsetup luksClose sda2_cryptIf the root partition is encrypted, then a message will be displayed upon shutdown
stopping early crypto disks... failedThis is a technical error. When shutting down, the file systems are always dismantled first, and only then the partition is dismounted. As a result, it turns out that the cryptsetup utility located on the root unmounted partition is no longer available for launch, which INIT tells us about. Without crutches, this problem cannot be solved, because. for this you need to consider options with transferring cryptsetup to a RAM disk
A similar situation occurs when using a software RAID containing a root partition. 8)
In this howto encryption method described AES256, other methods can be applied similarly (replacing the name of the method with the appropriate one). We will need the following packages:
# apt-get install loop-aes-utils loop-aes-modules-`uname -r`Note: if you are using a kernel for which the required loop-aes-modules is not in the repository, you can install the modules with the following commands:
# apt-get install module-assistant loop-aes-source # module-assistant a-i loop-aesOn initial stage we are preparing the disk to work with it using encryption.
Let's select the partition of the disk (or flash drive) that we want to encrypt, for example it will be /dev/sda2. Let's enter the command:
# losetup -e AES256 -T /dev/loop0 /dev/sda2After executing this command, all calls to the device /dev/loop0 will be encrypted and encrypted and redirected to the device /dev/sda2. Now we have both encrypted and unencrypted channels to the storage device. The data is encrypted using the password you specified when executing losetup.
Now we can, for example, format the device:
# mkfs.ext3 /dev/loop0We can mount it:
# mount /dev/loop0 /path/to/mountwe can disable encryption:
# losetup -d /dev/loop0and most importantly, we can encrypt the partition without data loss:
# dd if=/dev/sda2 of=/dev/loop0and also decrypt if we decide that encryption is not our method:
# dd if=/dev/loop0 of=/dev/sda2Well, the best part is, we can do file system integrity checks:
# fsck.ext3 /dev/loop0This feature is not available in all partition encryption methods.
If you already had a section entry /dev/sda2 in your /etc/fstab, then you just need to add options, and if not, then write something like this:
/dev/sda2 /path/to/mount ext3 loop,encryption=AES256 0 0Now when loading operating system you will be prompted for a password to mount.
If you do not want the download process to be interrupted by a password request, then you can add options auto,user on record /etc/fstab:
/dev/sda2 /path/to/mount ext3 loop,encryption=AES256,noauto,user 0 0Of course, you can mount manually (or from a script):
# mount /dev/sda2 /path/to/mount -o loop,encryption=AES256Sometimes you want to encrypt several sections with data at the same time, but so as not to enter a sea of passwords for each mount. For example, you have a flash drive that you carry from home to work, a portable hard drive, etc. Or just a few partitions / hard drives.
Let's say we have an encrypted partition /dev/sda2, which we mount to the directory every time we boot /mnt1. Appeared new hard drive /dev/sdb1 and we want it to be automatically mounted to the directory mnt2 when mounting the first one. You can of course create common system on something like LVM, but you can go the simpler way:
prescribe in fstab like the following line:
/dev/sda2 /mnt1 ext3 noatime,exec,loop,encryption=AES256 0 0The system, on boot, mounts the points in the same order as described in fstab, so if the first partition is not mounted, then the key to mount the second partition will remain unavailable and the second partition will also not be mounted.
The password is stored as plain/text this is certainly not very beautiful, but it is stored on an encrypted partition (which can be unmounted). You can use instead gpg-key, however, this will not add much security (if they can already steal the key, then it will not make much difference what this key will be), encryption option with gpg-key described in man losetup, here I will only give an example of recording in fstab:
/dev/sda2 /mnt1 ext3 noatime,exec,loop,encryption=AES256 0 0For more information on supported encryption algorithms, see man losetup, you can also see a description of other program options losetup.
If you have problems installing AES modules, then read the documentation that comes with the package loop-aes-source.
When installing a root partition on an encrypted disk, GRUB may show bugs in the main menu. This happens because the standard font /usr/share/grub/unicode.pf2 is not available. Copying the Font
cp /usr/share/grub/unicode.pf2 /boot/grub/Specify the setting
nano /etc/default/grub GRUB_FONT=/boot/grub/unicode.pf2Applying the setting:
update-grubTrueCrypt is no longer supported, but dm-crypt and LUKS are a great open source option to encrypt and use encrypted data.
Data security has become one of the biggest concerns among internet users. News of data theft from websites has become very common, but protecting your data is not only the responsibility of websites, there is a lot that we, as end users, can do for our own security. For example, just a few examples are using strong passwords, encrypting the hard drives that are located on our computers, and using secure connections. In particular, hard drive encryption is a good way to ensure security - it will not only protect you from any Trojans trying to steal your data over the network, but also from physical attacks.
In May of this year, development of the TrueCrypt application, a well-known open source tool for disk encryption, stopped. As many of you know, it was one of the very reliable tools for encrypting drives. It's sad to see a tool of this caliber disappear, but such is the greatness of the open source world that there are several other open source tools that can help you achieve security with disk encryption, which also have a lot of configuration settings. We will look at two of them - dm-crypt and LUKS - as an alternative to TrueCrypt for the Linux platform. Let's start with a quick look at dm-crypt and then LUKS.
This is basic information about a device using LUKS, which indicates what encryption is used, the encryption mode, the hash algorithm, and other cryptographic data.
The name of the application dm-crypt is short for device mapper-crypt (encrypt when mapping a device). As the name suggests, it is based on device mapping, a Linux kernel framework designed to map block devices to higher-level virtual block devices. When mapping devices, you can use several kernel features, such as dm-cache (creates hybrid volumes), dm-verity (designed to check the integrity of blocks, is part of Chrome OS) and also the very popular Docker. For cryptographic purposes, dm-crypt uses the Linux Kernel Crypto API framework.
So, to summarize, the dm-crypt application is a kernel-level encryption subsystem that offers transparent disk encryption: this means that the files are available immediately after the disk is mounted - there is no visible delay for the end user. To encrypt using dm-crypt you can simply specify one of the symmetric ciphers, the cipher mode, the key (any size allowed), the IV generation mode, and then create a new block device in /dev. Now, when writing to this device, encryption will occur, and when read, it will be decrypted. You can mount a filesystem on this device as usual, or you can use the dm-crypt device to create other constructs such as a RAID or LVM volume. The mapping table for dm-crypt is set as follows:
Here, the value of start-sector is typically 0, the value of size is the size of the device in sectors, and the target name is the name you want to give to the encrypted device. The target-mapping table consists of the following sections:
As we saw in the previous step, the dm-crypt application can encrypt/decrypt data on its own. But it has a few drawbacks - if you use dm-crypt directly, it won't create metadata on disk, and this can be a big problem if you want to ensure compatibility between different Linux distributions. Also, the dm-crypt application does not support the use of multiple keys, while in real life it is very important to use multiple keys.
It is for these reasons that the LUKS (Linux Unified Key Setup) methodology was born. LUKS is the standard for hard disk encryption in Linux, and standardization allows for compatibility across distributions. Multiple keys and passphrases are also supported. As part of this standardization, a LUKS header is added to the encrypted data, and this header contains all the information necessary for configuration. When there is such a header with data, then users can easily switch to any other distribution. The dm-crypt project currently recommends using LUKS as the preferred way to set up disk encryption. Let's look at how to install the cryptsetup utility and how to use it to create LUKS-based volumes.
The kernel-level functionality that dm-crypt uses is already available in all Linux distributions; we only need an interface to them. We will be using the cryptsetup utility, which allows you to create volumes using dm-crypt, the LUKS standard, and the good old TrueCrypt application. In order to install cryptsetup on Debian/Ubuntu distributions, you can use the following commands:
$ sudo apt-get update $ sudo apt-get install cryptsetup
The first command synchronizes the rocket index files with the contents of their repositories: it gets information about the latest versions of all available packages. The second command will download and install the cryptsetup package on your computer. If you are using the RHEL/Fedora/CentOS distribution, you can use the yum command to install the cryptsetup utility.
$ yum install cryptsetup-luks
Now that the cryptsetup utility has been successfully installed, we need to create a target file that will hold the LUKS container. Although there are many ways to create such a file, a number of conditions must be met when creating it:
In creating a file that will satisfy the above conditions, the dd command can help us, although it will work relatively slowly. Just use it with the special device file /dev/random specified as input and the target file to be specified as output. An example command looks like this:
$ dd if=/dev/random of=/home/nitish/basefile bs=1M count=128
This will create a 128 MB file called basefile in the /home/nitish directory. However, please note that this command may take a long time to complete; in the system that our expert used, it took an hour.
After you have created the target file, you need to create a LUKS section in this file. This section serves as the base layer upon which all data encryption is built. In addition, the header of this section (LUKS header) contains all the information required for compatibility with other devices. To create a LUKS partition, use the cryptsetup command:
$ cryptsetup -y luksFormat /home/nitish/basefile
After you agree that the data inside the basefile will be permanently deleted, enter the passphrase and then confirm it, the LUKS partition will be created. You can check this with the following file command:
$filebasefile
Please note that the phrase you enter here will be used to decrypt the data. It is very important to memorize it and store it in a safe place, because if you forget it, you will almost certainly lose all the data on the encrypted partition.
The LUKS container we created in the previous step is now available as a file. In our example, this is /home/nitish/basefile. The cryptsetup utility allows you to open a LUKS container as an independent device. To do this, first map the container file to the device name and then mount the device. The display command looks like this:
After you successfully enter the passphrase created in the previous step, the LUKS container will be mapped to volume1. What actually happens is that the file is opened as a local loopback device, so that the rest of the system can now treat the file as if it were a real device.
The LUKS container file is now available on the system as a regular device. Before we can use it for normal operations, we must format it and create a file system on it. You can use any file system that is supported on your system. In my example, we used ext4 as it is the newest file system for Linux systems.
$ mkfs.ext4 -j /dev/mapper/volume1
Once the device has been successfully formatted, the next step is to mount it. You must first create a mount point, preferably in /mnt (common sense).
$ mkdir /mnt/files
Now we mount:
To cross-check, use the df –h command - you will see the device "/dev/mapper/volume1" at the end of the list of mounted devices. It can be seen that the LUKS header already occupies some space in the device.
Thanks to this step, you can now use a LUKS device with an ext4 filesystem. Just use this file storage device - everything you write to this device will be encrypted, and everything you read from it will be decrypted and shown to you.
We have followed several steps in order to achieve this result, and if you are not very clear on how it all works, you will most likely be confused about what needs to be done only once (required for installation), and that should be done regularly when using encryption. Let's consider the following scenario: you successfully completed all the steps above and then turned off your computer. The next day, when you start your computer, you are unable to find the mounted device - where did it go? To deal with all this, you need to keep in mind that after starting the system, you need to mount the LUKS container, and unmount it before stopping the computer.
To access the LUKS file, each time you turn on your computer, follow these steps, and then safely close the file before you turn off your computer:
Open the LUKS file (i.e. /home/nitish/basefile) and enter the password. The command looks like this:
$ cryptsetup luksOpen /home/nitish/basefile volume1
Once the file is open, mount it (if it doesn't mount automatically):
$ mount /dev/mapper/volume1 /mnt/files
Now you can use the mounted device as a regular disk and read from or write data to it.
Once done, unmount the device like this:
$ umount /mnt/files
After successfully unmounting, close the LUKS file:
$ cryptsetup luksClose volume1
Most loss of data stored in a LUKS container is due to corruption of the LUKS header or key slots. In addition to the fact that LUKS headers can be corrupted even due to accidental overwriting in header memory, a complete hard disk failure is also possible in real conditions. The best way to protect yourself from such problems is a backup. Let's see what backup options are available.
To back up the LUKS header file, specify the luksHeaderBackup parameter in the command:
$ sudo cryptsetup luksHeaderBackup /home/nitish/basefile --header-backup-file /home/nitish/backupfile
Or, if you want to restore a file from a backup, specify the luksHeaderRestore parameter in the command:
$ sudo cryptsetup luksHeaderRestore /home/nitish/basefile --header-backup-file /home/nitish/backupfile
You can use the isLuks parameter to check for a LUKS header file and verify that the file you are dealing with corresponds to an actual LUKS device.
$ sudo cryptsetup -v isLuks /home/nitish/basefile
We've already seen how to back up LUKS header files, but backing up a LUKS header doesn't really protect against a total disk failure, so you need to back up the entire partition with the following cat command:
$ cat /home/nitish/basefile > basefile.img
There are a few other settings that can be useful when using dm-crypt LUKS encryption. Let's take a look at them.
To dump the LUKS header, the cryptsetup command has the luksDump option. It will allow you to take a snapshot of the LUKS header file of the device you are using. An example command looks like this:
$ cryptsetup luksDump /home/nitish/basefile
At the beginning of this article, we mentioned that LUKS supports multiple keys. Let's see this in action now by adding a new key slot ( note per.: key slot - turnkey place):
$ cryptsetup luksAddKey --Key-slot 1 /home/nitish/basefile
This command adds a key to key slot number 1, but only after you enter the current password (the key present in key slot 0). There are eight key slots in total, and you can decrypt data using any key. If you dump the header after adding the second key, you will see that the second key slot is occupied.
You can remove key slots like this:
$ cryptsetup luksRemoveKey /home/nitish/basefile
This will remove the key slot with the highest slot number. Be careful not to delete all slots or your data will be permanently lost.
There are many reasons to encrypt the data on your hard drive, but the cost of data security is slower system performance. The purpose of this article is to compare performance when working with a disk encrypted by different means.
To make the difference more dramatic, we chose not an ultra-modern, but an average car. The usual 500 GB mechanical hard drive, dual-core AMD at 2.2 GHz, 4 gigabytes of RAM, 64-bit Windows 7 SP 1. No antiviruses or other programs will be launched during the test so that nothing could affect the results.
To evaluate performance, I chose CrystalDiskMark. As for the tested encryption tools, I settled on the following list: BitLocker, TrueCrypt, VeraCrypt, CipherShed, Symantec Endpoint Encryption and CyberSafe Top Secret.
It is the standard disk encryption tool built into Microsoft Windows. Many people simply use it without installing third-party programs. Indeed, why, if everything is already in the system? On the one hand, right. On the other hand, the code is closed, and there is no certainty that no backdoors were left in it for the FBI and other interested people.
The disk is encrypted using the AES algorithm with a key length of 128 or 256 bits. The key can be stored in the Trusted Platform Module, on the computer itself or on a flash drive.
If TPM is used, then when the computer boots up, the key can be obtained immediately from it or after authentication. You can log in using a key on a USB flash drive or by entering a PIN code from the keyboard. Combinations of these methods give many options for restricting access: just TPM, TPM and USB, TPM and PIN, or all three at once.
BitLocker has two undeniable advantages: firstly, it can be controlled through group policies; second, it encrypts volumes, not physical drives. This allows you to encrypt an array of multiple drives, which some other encryption tools cannot do. BitLocker also supports the GUID Partition Table (GPT), which even the most advanced TruCrypt fork VeraCrypt cannot boast of. To encrypt a system GPT disk with it, you will first have to convert it to MBR format. In the case of BitLocker, this is not required.
In general, there is only one drawback - closed source. If you're keeping secrets from the household, BitLocker is great. If your disk is full of documents of national importance, it is better to find something else.
If you ask Google, it will find an interesting Elcomsoft Forensic Disk Decryptor program suitable for decrypting BitLocker, TrueCrypt and PGP drives. In the framework of this article, I will not test it, but I will share my impressions of another utility from Elcomsoft, namely Advanced EFS Data Recovery. It was excellent at decrypting EFS folders, but on the condition that no user password was set. If you set a password of at least 1234, the program turned out to be powerless. In any case, I failed to decrypt the encrypted EFS folder belonging to the user with the password 111. I think the situation will be the same with the Forensic Disk Decryptor product.
This is a legendary disk encryption program that was discontinued in 2012. The story that happened to TrueCrypt is still shrouded in darkness, and no one really knows why the developer decided to stop supporting his brainchild.
There are only bits of information that do not allow you to put the puzzle together. So, in 2013, fundraising began for an independent audit of TrueCrypt. The reason was information received from Edward Snowden about the intentional weakening of TrueCrypt encryption tools. More than 60 thousand dollars were collected for the audit. At the beginning of April 2015, the work was completed, but no serious errors, vulnerabilities or other significant flaws in the application architecture were identified.
As soon as the audit ended, TrueCrypt was again at the center of the scandal. ESET specialists published a report that the Russian-language version of TrueCrypt 7.1a, downloaded from truecrypt.ru, contained malware. Moreover, the truecrypt.ru site itself was used as a command center - commands were sent from it to infected computers. In general, be vigilant and do not download programs from anywhere.
TrueCrypt benefits include open source, now independently audited for reliability, and support for Windows dynamic volumes. Disadvantages: the program is no longer developed, and the developers did not have time to implement UEFI / GPT support. But if the goal is to encrypt one non-system drive, then it doesn't matter.
Unlike BitLocker, where only AES is supported, TrueCrypt also has Serpent and Twofish. To generate encryption keys, salt and header key, the program allows you to select one of three hash functions: HMAC-RIPEMD-160, HMAC-Whirlpool, HMAC-SHA-512. However, a lot has already been written about TrueCrypt, so we will not repeat ourselves.
The most advanced TrueCrypt clone. It has its own format, although it is possible to work in TrueCrypt mode, which supports encrypted and virtual disks in the TrueCrypt format. Unlike CipherShed, VeraCrypt can be installed on the same computer at the same time as TrueCrypt.
TrueCrypt uses 1000 iterations to generate the key that will encrypt the system partition, while VeraCrypt uses 327,661 iterations. For standard (non-system) partitions, VeraCrypt uses 655,331 iterations for the RIPEMD-160 hash function and 500,000 iterations for SHA-2 and Whirlpool. This makes encrypted partitions much more resistant to brute-force attacks, but also significantly reduces the performance of working with such a partition. How much, we will soon find out.
Among the advantages of VeraCrypt are open source code, as well as a proprietary and more secure virtual and encrypted disk format compared to TrueCrypt. The disadvantages are the same as in the case of the progenitor - the lack of support for UEFI / GPT. It is still impossible to encrypt the system GPT disk, but the developers claim that they are working on this problem and soon such encryption will be available. But they have been working on this for two years now (since 2014), and when there will be a release with GPT support and whether it will be at all, it is not yet known.
Another clone of TrueCrypt. Unlike VeraCrypt, it uses the original TrueCrypt format, so you can expect its performance to be close to that of TrueCrypt.
The advantages and disadvantages are the same, although the inability to install TrueCrypt and CipherShed on the same computer can be added to the disadvantages. Moreover, if you try to install CipherShed on a machine with TrueCrypt already installed, the installer offers to remove the previous program, but fails to do the job.
In 2010, Symantec bought the rights to the PGPdisk program. The result was products such as PGP Desktop and, subsequently, Endpoint Encryption. That is what we will consider. The program is, of course, proprietary, the source code is closed, and one license costs 64 euros. But there is support for GPT, but only starting with Windows 8.
In other words, if you need GPT support and want to encrypt system partition, you will have to choose between two proprietary solutions: BitLocker and Endpoint Encryption. It is unlikely, of course, that a home user will install Endpoint Encryption. The problem is that this requires Symantec Drive Encryption, which requires an agent and a Symantec Endpoint Encryption (SEE) management server to install, and the server wants to install IIS 6.0 as well. Isn't it too much goodness for one disk encryption program? We went through all this just to measure performance.
So, we proceed to the most interesting, namely testing. The first step is to check the performance of the disk without encryption. Our “victim” will be a 28 GB hard disk partition (regular, not SSD), formatted as NTFS.
Open CrystalDiskMark, select the number of passes, the size of the temporary file (in all tests we will use 1 Gbps) and the disk itself. It is worth noting that the number of passes practically does not affect the results. The first screenshot shows the results of measuring the performance of a disk without encryption with a number of passes of 5, the second - with a number of passes of 3. As you can see, the results are almost identical, so we will focus on three passes.
CrystalDiskMark results should be interpreted as follows:
Let's start with BitLocker. It took 19 minutes to encrypt a 28 GB partition.
The subscription will allow you to read ALL paid materials of the site, including this article, during the specified period. We accept payment by bank cards, electronic money and transfers from the accounts of mobile operators.
The privacy and security requirements of a computer are entirely determined by the nature of the data stored on it. It is one thing if your computer serves as an entertainment station and there is nothing on it except for a few toys and a daddy with photos of your beloved cat, and quite another if there is data on the hard drive that is a trade secret, potentially of interest to competitors.
The first "line of defense" is the password to enter the system, which is requested every time the computer is turned on.
The next level of protection is access rights at the file system level. A user without permission privileges will receive an error when trying to access the files.
However, the described methods have one extremely significant drawback. They both work at the operating system level and can be bypassed relatively easily if you have a little time and physical access to the computer (for example, by booting from a USB flash drive, you can reset the administrative password or change file permissions). Complete confidence in the security and confidentiality of data can only be obtained if the achievements of cryptography are used and reliably. Below we consider two ways of such protection.
The first method considered today will be the built-in crypto protection from Microsoft. Encryption, called BitLocker, first appeared in Windows 8. It will not work to secure a separate folder or file with it, only encryption of the entire drive is available. This, in particular, implies the fact that it is impossible to encrypt the system disk (the system will not be able to boot), it is also impossible to store important data in system libraries such as "My Documents" (by default they are located on the system partition).
To enable built-in encryption, do the following:
The second cryptographic utility reviewed today is DiskCryptor, a free and open source solution. To use it, follow the instructions below:
The undoubted advantage of this utility compared to the BitLocker mechanism is that it can be used on systems that came out before Windows 8 (even the discontinued Windows XP is supported). But DiskCryptor also has several significant disadvantages:
Summarizing, I can say that if an OS is installed on the computer starting with Windows 8, then it is better to use the built-in functionality.
This documentation has been archived and is no longer maintained.
Purpose: Windows Server 2008, Windows Server 2008 R2, Windows Vista
BitLocker Drive Encryption is a data protection feature available in Windows Server 2008 R2 and some editions of Windows 7. BitLocker integration into the operating system counters data theft or vulnerability threats by protecting against lost, stolen, or improperly decommissioned computers.
Data on a lost or stolen computer is vulnerable to unauthorized access, either by hacking software or by connecting the computer's hard drive to another computer. BitLocker encryption helps prevent unauthorized access to data, increasing file and system security. BitLocker encryption also helps keep data inaccessible when decommissioning or reusing computers protected with BitLocker encryption.
BitLocker encryption provides maximum protection when used with Trusted Platform Module (TPM) version 1.2. The TPM is a hardware component installed in many modern computers by their manufacturers. It works in conjunction with BitLocker encryption to help protect user data and ensure that the computer has not been tampered with while the system has been shut down.
On computers without TPM 1.2 installed, BitLocker encryption can still be used to encrypt the operating system drive. Windows systems. However, this implementation will require the user to insert a USB startup key to start or wake the computer, and does not provide the pre-startup system integrity check provided by BitLocker encryption with TPM.
In addition to the TPM, BitLocker encryption provides the ability to block the normal startup process until the user enters a personal identification number (PIN) or inserts a removable device, such as a USB flash drive, containing a startup key. These additional security measures provide multi-factor authentication and ensure that the computer will not start or wake up from sleep until the correct PIN or startup key is provided.
BitLocker encryption can use a TPM to verify the integrity of boot components and boot configuration data. This helps ensure that when BitLocker encryption is used, the encrypted drive will only be available if these components have not been tampered with and the encrypted drive is installed on the source computer.
BitLocker encryption helps ensure the integrity of the startup process through the following steps.
To use BitLocker, your computer must meet certain requirements.
BitLocker encryption is installed automatically as part of the operating system installation. But BitLocker encryption is not available until it is enabled using the BitLocker Setup Wizard, which can be launched either from the Control Panel or by right-clicking the drive in File Explorer.
At any time after installation and initial setup of the operating system, an administrator can use the BitLocker Setup Wizard to initialize BitLocker encryption. The initialization process consists of two steps:
When initializing BitLocker encryption local administrator you should also create a recovery password and recovery key. Without a recovery password or recovery key, all data on an encrypted drive may be inaccessible if there is a problem with a BitLocker-encrypted drive.
For detailed information about configuring and deploying BitLocker encryption, see the Windows BitLocker Drive Encryption Walkthrough (http://go.microsoft.com/fwlink/?LinkID=140225).
BitLocker encryption can use existing Domain Services infrastructure Active Directory(AD DS) organizations for remote storage of recovery keys. BitLocker encryption provides a wizard for configuration and management, and extensibility and management through a scriptable WMI interface. In addition, BitLocker encryption provides a recovery console built into the boot process to allow the user or help desk personnel to regain access to a locked computer.
For more information about scripting BitLocker encryption, see Win32_EncryptableVolume (http://go.microsoft.com/fwlink/?LinkId=85983).
Contrary to popular belief, the DRAM memory used in most modern computers retains data even after a power outage for several seconds or minutes, moreover, this happens at room temperature and even if the chip is removed from the motherboard. This time is quite enough to take a complete dump. random access memory. We will show that this phenomenon allows an attacker who has physical access to the system to bypass the OS functions for protecting data about cryptographic keys. We will show how reboot can be used to make successful attacks on known hard drive encryption systems without the use of any specialized devices or materials. We will experimentally determine the degree and probability of remanence retention and show that the time for which data can be taken can be significantly increased using simple tricks. New methods will also be proposed for finding cryptographic keys in memory dumps and correcting errors associated with missing bits. We will also talk about several ways to reduce these risks, but we do not know of a simple solution.
Most experts assume that data from the computer's RAM is erased almost instantly after a power outage, or consider that residual data is extremely difficult to retrieve without the use of special equipment. We will show that these assumptions are incorrect. Conventional DRAM memory loses data gradually over several seconds, even at normal temperatures, and even if the memory chip is removed from the motherboard, data will remain in it for minutes or even hours, provided that the chip is stored at low temperatures. Residual data can be recovered using simple methods that require short-term physical access to the computer.
We will show a number of attacks that, using the remanence effects of DRAM, will allow us to recover the encryption keys stored in memory. This poses a real threat to laptop users who rely on hard drive encryption systems. Indeed, if an attacker steals a laptop, at the moment when the encrypted disk is connected, he will be able to carry out one of our attacks to access the contents, even if the laptop itself is locked or in sleep mode. We will demonstrate this by successfully attacking several popular encryption systems such as BitLocker, TrueCrypt, and FileVault. These attacks should also be successful against other encryption systems.
Although we have focused our efforts on encryption systems hard drives, in the case of physical access to an attacker's computer, any important information stored in RAM can become an object of attack. It is likely that many other security systems are vulnerable. For example, we found that Mac OS X leaves account passwords in memory where we could retrieve them, and we also attacked Apache's private RSA keys.
Some members of the information security and semiconductor physics communities were already aware of the DRAM remanence effect, there was very little information about it. As a result, many who design, develop, or use security systems are simply unfamiliar with this phenomenon and how easily it can be exploited by an attacker. To the best of our knowledge, this is the first detailed work examining the implications of these phenomena for information security.
Encryption of hard drives is a well-known method of protection against data theft. Many believe that hard drive encryption systems will protect their data, even if an attacker has gained physical access to the computer (in fact, they are needed for this, ed.). California law, passed in 2002, requires reporting possible cases disclosure of personal data, only if the data was not encrypted, because data encryption is considered to be a sufficient protective measure. Although the law does not describe any specific technical solutions, many experts recommend the use of hard drive or partition encryption systems, which will be considered sufficient measures for protection. The results of our study showed that belief in disk encryption is unfounded. An attacker, far from being the most highly skilled, can bypass many widely used encryption systems if a laptop with data is stolen while it was on or in sleep mode. And data on a laptop can be read even when it is on an encrypted drive, so using hard drive encryption systems is not a sufficient measure.
We used several types of attacks on known hard drive encryption systems. The installation of encrypted disks and verification of the correctness of the detected encryption keys took the most time. Obtaining a RAM image and searching for keys took only a few minutes and was fully automated. There is reason to believe that most hard drive encryption systems are susceptible to such attacks.
BitLocker is a system included with some OS versions Windows Vista. It functions as a driver working between the file system and the driver hard drive, encrypting and decrypting selected sectors on demand. The keys used for encryption are in RAM as long as the encrypted disk is unmounted.
To encrypt each sector of a hard drive, BitLocker uses the same key pair generated by the AES algorithm: a sector encryption key and an encryption key operating in cipher block chaining (CBC) mode. These two keys are in turn encrypted with the master key. To encrypt a sector, a binary plaintext addition procedure is performed with a session key generated by encrypting the sector offset byte with the sector encryption key. Then, the received data is processed by two mixing functions that use the Elephant algorithm developed by Microsoft. These keyless functions are used to increase the number of changes to all bits of the cipher and, accordingly, increase the uncertainty of the encrypted sector data. At the last stage, the data is encrypted with the AES algorithm in CBC mode, using the appropriate encryption key. The initialization vector is determined by encrypting the sector offset byte with the encryption key used in CBC mode.
We have implemented a fully automated demo attack called BitUnlocker. This uses an external USB drive with Linux OS and a modified bootloader based on SYSLINUX and the FUSE driver that allows you to connect BitLocker encrypted drives to Linux OS. On a test computer running Windows Vista, the power was turned off, a USB hard drive was connected, and booted from it. After that, BitUnlocker automatically dumped the RAM to an external drive, searched for possible keys using the keyfind program, tried all the suitable options (pairs of the sector encryption key and the CBC mode key), and if successful, connected the encrypted drive. As soon as the disk was connected, it became possible to work with it like with any other disk. On a modern laptop with 2 gigabytes of RAM, the process took about 25 minutes.
It is noteworthy that this attack became possible to carry out without reverse engineering of any software. The Microsoft documentation describes the BitLocker system sufficiently to understand the role of the sector encryption key and the CBC mode key and create your own program that implements the entire process.
The main difference between BitLocker and other programs of this class is the way in which keys are stored when the encrypted drive is disconnected. By default, in basic mode, BitLocker protects the master key only with the help of the TPM module, which exists on many modern PCs. This method, which seems to be widely used, is especially vulnerable to our attack, since it allows you to get encryption keys even if the computer has been turned off for a long time, because when the PC boots up, the keys are automatically loaded into RAM (until login window) without entering any authentication data.
Apparently, Microsoft experts are familiar with this problem and therefore recommend configuring BitLocker in an improved mode, where keys are protected not only with TPM, but also with a password or a key on an external USB drive. But, even in this mode, the system is vulnerable if an attacker gains physical access to the PC while it is running (it can even be locked or in sleep mode, (states - just turned off or hibernate in this case are considered not affected by this attack).
Apple's FileVault system has been partially researched and reverse engineered. On Mac OS X 10.4, FileVault uses a 128-bit AES key in CBC mode. When the user's password is entered, a header containing the AES key and a second K2 key is decrypted, used to calculate the initialization vectors. The initialization vector for the Ith disk block is calculated as HMAC-SHA1 K2(I).
We used our EFI program to capture RAM images to retrieve data from a Macintosh computer (based on an Intel processor) with a FileVault encrypted drive attached. The keyfind program then found the FileVault AES keys automatically without error.
Without an initialization vector, but with the received AES key, it becomes possible to decrypt 4080 out of 4096 bytes of each disk block (everything except the first AES block). We made sure that the initialization vector is also in the dump. Assuming the data hasn't been corrupted yet, an attacker can determine the vector by trying all the 160-bit strings in the dump one by one and checking if they can form a possible plaintext when added binary to the decrypted first part of the block. Together, using programs like vilefault, AES keys and an initialization vector allow you to completely decrypt an encrypted disk.
While investigating FileVault, we found that Mac OS X 10.4 and 10.5 leave multiple copies of a user's password in memory, where they are vulnerable to this attack. Passwords accounts often used to protect keys, which in turn can be used to protect passphrases on FileVault encrypted drives.
TrueCrypt is a popular open source encryption system that runs on Windows, MacOS and Linux. It supports many algorithms including AES, Serpent and Twofish. In version 4, all algorithms worked in LRW mode; in the current 5th version, they use the XTS mode. TrueCrypt stores the encryption key and tweak key in the partition header on each drive, which is encrypted with a different key derived from the user's entered password.
We tested TrueCrypt 4.3a and 5.0a running under Linux OS. We connected a disk encrypted with a 256-bit AES key, then turned off the power and used our own memory dump software to boot. In both cases, keyfind found a 256-bit intact encryption key. Also, in the case of TrueCrypt 5.0.a, keyfind was able to recover the XTS mode tweak key.
To decrypt disks created by TrueCrypt 4, you need to tweak the LRW mode key. We found that the system stores it in four words before the key AES key schedule. In our dump, the LRW key was not corrupted. (In the event of errors, we would still be able to recover the key).
The Linux kernel, starting with version 2.6, includes built-in support for dm-crypt, a disk encryption subsystem. Dm-crypt uses many algorithms and modes, but by default it uses a 128-bit AES cipher in CBC mode with non-key-based initialization vectors.
We tested the created dm-crypt partition using the LUKS (Linux Unified Key Setup) branch of the cryptsetup utility and the 2.6.20 kernel. The disk was encrypted using AES in CBC mode. We turned off the power for a while and using a modified PXE bootloader, we did a memory dump. The keyfind program found a valid 128-bit AES key, which was recovered without any errors. After recovering it, an attacker can decrypt and mount the dm-crypt encrypted partition by modifying the cryptsetup utility so that it accepts the keys in the required format.
The implementation of protection against attacks on RAM is not trivial, since the cryptographic keys must be stored somewhere. We propose to focus on destroying or hiding the keys before an attacker can gain physical access to the PC, preventing the main memory dump software from running, physically protecting the RAM chips, and, if possible, reducing the data retention period in the RAM.
First of all, it is necessary, if possible, to avoid storing keys in RAM. It is necessary to overwrite key information when it is no longer used, and prevent data from being copied to swap files. Memory must be cleared in advance by means of the OS or additional libraries. Naturally, these measures will not protect the keys currently in use, as they must be stored in memory, such as those used for encrypted disks or on secure web servers.
Also, the RAM must be cleared during the boot process. Some PCs can be configured to clear RAM on boot using a clear POST request (Power-on Self-Test) before booting the OS. If the attacker cannot prevent the execution of this request, then on this PC he will not be able to make a memory dump with important information. But, he still has the opportunity to pull out the RAM chips and insert them into another PC with the BIOS settings he needs.
Many of our attacks were implemented using network boot or removable media. The PC must be configured to require an administrator password to boot from these sources. But, it should be noted that even if the system is configured to boot only from the main hard drive, the attacker can change HDD, or in many cases, reset the computer's NVRAM to revert to the original BIOS settings.
The results of the study showed that simply locking the PC desktop (that is, the OS continues to work, but in order to start interacting with it, a password must be entered) does not protect the contents of RAM. Sleep mode is not effective even if the PC is blocked when returning from sleep mode, because an attacker can activate the return from sleep mode, then restart the laptop and make a memory dump. The hibernate mode (the contents of the RAM is copied to the hard disk) will also not help, except when using key information on alienated media to restore normal operation.
With most hard drive encryption systems, users can protect themselves by shutting down the PC. (The Bitlocker system in the basic mode of the TPM module remains vulnerable, since the disk will be connected automatically when the PC is turned on). The contents of the memory may be retained for a short period after being turned off, so it is recommended that you monitor your workstation for a couple more minutes. Despite its effectiveness, this measure is extremely inconvenient due to the long loading of workstations.
Hibernation can be secured in the following ways: require a password or some other secret to "wake up" the workstation, and encrypt the contents of memory with a key derived from this password. The password must be strong, as an attacker can dump the memory and then try to guess the password by brute force. If it is not possible to encrypt the entire memory, only those areas that contain key information need to be encrypted. Some systems may be configured to enter this type of protected sleep, although this is usually not the default setting.
Our research has shown that using precomputation to speed up cryptographic operations makes key information more vulnerable. Precomputation leads to the fact that in memory there is redundant information about key data, which allows an attacker to recover the keys even if there are errors. For example, as described in Section 5, information about the iteration keys of the AES and DES algorithms is extremely redundant and useful to an attacker.
Rejecting precomputations will reduce performance, as potentially complex calculations will have to be repeated. But, for example, you can cache pre-calculated values for a certain period of time and erase the received data if they are not used during this interval. This approach represents a compromise between security and system performance.
Another way to prevent key recovery is to change the key information stored in memory in such a way as to make key recovery more difficult due to various errors. This method was considered in theory, where a function was shown to be resistant to disclosure, whose inputs remain hidden even if almost all of the outputs were discovered, which is very similar to the operation of one-way functions.
In practice, imagine that we have a 256-bit AES key K, which in this moment not used, but will be needed later. We can't overwrite it, but we want to make it resistant to recovery attempts. One way to achieve this is to allocate a large B-bit data area, fill it with random data R, and then store in memory the result of the following transformation K + H (R) (binary summation, ed.), where H is a hash function, such as SHA-256.
Now imagine that the electricity was turned off, this will cause d bits in this area to be changed. If the hash function is strong, when attempting to recover key K, an attacker can only rely on being able to guess which bits of area B have been changed out of about half that could have changed. If d bits have been changed, the attacker will have to search for a region of size (B/2+d)/d to find the correct values of R and only then recover the key K. If the region B is large, such a search can be very long, even if d is relatively small.
Theoretically, we can store all the keys in this way, calculating each key only when we need it, and deleting it when we don't need it. Thus, by applying the above method, we can store the keys in memory.
Some of our attacks relied on having physical access to memory chips. Such attacks can be prevented by physical memory protection. For example, the memory modules are kept in a closed PC case, or sealed with epoxy to prevent attempts to remove or access them. Also, it is possible to implement memory overwriting as a response to low temperatures or attempts to open the case. This method will require the installation of sensors with an independent power supply system. Many of these methods involve tamper-proof hardware (such as the IBM 4758 coprocessor) and can greatly increase the cost of a workstation. On the other hand, using memory soldered to the motherboard will be much cheaper.
You can change the PC architecture. Which is impossible for already used PCs, but it will allow you to secure new ones.
The first approach is to design DRAM modules in such a way that they erase all data faster. This can be tricky, as the goal of erasing data as quickly as possible conflicts with the other goal of not losing data between memory refresh periods.
Another approach is to add key storage hardware that is guaranteed to erase all information from its storage on startup, restart, and shutdown. Thus, we will get a secure place to store several keys, although the vulnerability associated with their pre-computation will remain.
Other experts have proposed an architecture in which the contents of the memory will be permanently encrypted. If, in addition to this, we implement the erasing of keys on reboot and power outage, then this method will provide sufficient protection against the attacks we have described.
Hardware corresponding to the concept of "trusted computing", for example, in the form of TPM modules, is already used in some PCs. Despite their usefulness in protecting against some attacks, in their current form, such equipment does not help prevent the attacks we have described.
The TPM modules used do not implement full encryption. Instead, they watch the boot process to decide whether it is safe to boot the key into RAM or not. If the software needs to use a key, then the following technology can be implemented: the key, in a usable form, will not be stored in RAM until the boot process goes according to the expected scenario. But, as soon as the key is in RAM, it immediately becomes a target for our attacks. TPM modules can prevent the key from being loaded into memory, but they do not prevent it from being read from memory.
Contrary to popular belief, DRAM modules store data for a relatively long time when disabled. Our experiments have shown that this phenomenon makes it possible to implement a whole class of attacks that allow you to get important data, such as encryption keys, from RAM, despite the OS's attempts to protect its contents. The attacks we describe are realizable in practice, and our examples of attacks on popular encryption systems prove this.
But other types of software are also vulnerable. Digital rights management (DRM) systems often use symmetric keys stored in memory, and these can also be obtained using the methods described. As we have shown, SSL-enabled web servers are also vulnerable because they store in memory the private keys needed to create SSL sessions. Our methods of searching for key information are likely to be effective for finding passwords, account numbers, and any other important information stored in RAM.
It seems that there is no easy way to eliminate the vulnerabilities found. Changing the software will most likely not be effective; hardware changes will help, but the time and resource costs will be high; the technology of "trusted computing" in its current form is also not very effective, since it cannot protect the keys that are in memory.
In our opinion, laptops, which are often in and operating in modes vulnerable to these attacks, are most exposed to this risk. The presence of such risks shows that disk encryption protects important data to a lesser extent than is commonly believed.
As a result, you may have to consider DRAM memory as an untrusted component of a modern PC, and avoid processing important confidential information.
