TrueCrypt 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 sites, 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.

Resources

Step 01: Considering Dm-crypt

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 block integrity, 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, start-sector is typically 0, size is the size of the device in sectors, and target name is the name you want to give the encrypted device. The target-mapping table consists of the following sections:

[<#opt_params> ]

Step 02: Considering LUKS

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, whereas in real life situations 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.

Step 03: Installation

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

Step 04: Creating a target file

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:

  • The file should not consist of several parts located in different places on the disk, that is, when creating it, you should immediately allocate a sufficient amount of memory for it.
  • The entire file must be filled with random data so that no one can tell where the data used in encryption will be located.

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.

Step 05: Create dm-crypt LUKS

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.

Step 06: Create and mount a file system

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.

Step 07: File system - continued

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.

Step 08: Using an encrypted disk

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

Step 09: Backup

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

Step 10: Various settings

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.

Semenenko V.

When you install the Ubuntu operating system, you may not think about setting up data encryption in it. Or there may be a situation where you add a user to the system without encrypting his home directory. But now you have changed your mind and decided to configure the protection of this directory. In other words, you (or another user on the computer) want a feature that doesn't currently exist...

Creating an Encrypted Partition in Ubuntu

How can you add encryption capability to an already installed Ubuntu Linux system?

Luckily, it's fairly easy to implement. To do this, just follow three basic steps:

  • create an encrypted copy of your home directory;
  • delete the original unencrypted home directory;
  • encrypt the swap partition (performed only once, when installing an Ubuntu system or when following this guide step by step).

The steps in this article were performed on a fully updated Ubuntu Precise 12.04 system.

Training

Due to a current bug in Ubuntu Linux, you cannot log in if the login graphic is in the user's encrypted home folder. If the user has changed the default appearance, make sure that it is also not located in the user's home folder.

Creating an encrypted copy of the user's home directory is a secure procedure. However, it is worth paying attention that a certain amount of hard disk space is required for its implementation. If it turns out that there is too little space, you need to back up the data, then delete all large files (for example, movies) from it and restore them from this backup after encryption is completed. I generally recommend that you back up all your data to prevent possible problems.

Using your preferred package manager, install the encrypt-utils program.

Encryption

In this tutorial, I will use paddy's login as the username to act on. You need to replace it with the name of the user whose home directory will be encrypted.

Reboot Ubuntu Linux and go into "Recovery Mode". A word of advice - while the system boots up, press and hold the Shift key to open the Grub menu. Usually the line "Recovery Mode" (Recovery Mode) is located second from the top in the list of this bootloader.

From the recovery mode menu, select "Drop" to display the command line prompt for the root account.

To fix the programming error mentioned at the beginning of this article, enter the following two commands:

mount --options remount,rw /
mount --all

Now we can create an encrypted copy of the paddy user's home directory. To do this, enter the command below. At the same time, take the trouble to remember your own password, as this utility will require it to complete the operation:

When the encryption process is complete, you will see several warnings. You can ignore them. But you will need to remember the path to the temporary folder created by this command. Its appearance will be something like this: /home/paddy.ChPzzxqD

In this case, the last eight characters (after the dot) are a random set. You will need this directory in the next "Complete" or "Return to Initial State" steps, which will be discussed later.

Reboot your Ubuntu Linux system. To do this, enter the command: reboot now

It may take a few seconds after typing and running the command, so be patient.

Completion

Log in to your Ubuntu system in the usual way, as you did every time. Check that everything works as before.

If something is wrong, you can immediately go to the "Return to the original state" item.

If everything in the system works fine, completed the final steps.

Open the terminal and enter the command to delete the temporary directory. To do this, you will need to remember the path to the temporary folder that was created when the home directory was encrypted.

sudo rm -R /home/paddy.ChPzzxqD

Restore the data that you deleted (if any) in the "Preparation" step.

Open the terminal again and enter the command to encrypt the swap partition. If you previously had a user with home directory encryption configured, you can safely skip this step: sudo ecryptfs-setup-swap

Reboot again.

Return to original state

If the encryption process failed, you will need to repeat the previous steps again.

Run commands:

mount --options remount,rw /
mount --all
ecryptfs-migrate-home --user paddy

Then enter the command to view the contents of the temporary folder created during the encryption process. To do this, you again need to remember the path to it. This should not generate any errors. If they do, then you need help.

ls -l /home/paddy.ChPzzxqD

Now complete the reset process by issuing three commands:

cd /home
rm -R paddy .ecryptfs/paddy
mv paddy.ChPzzxqD

Reboot again.

Hope the above steps helped you. If you have unresolvable problems, you can post a request on my Ubuntu forum thread.

Sleep mode when encrypted

Most users often wonder why there is no hibernation (hibernate) in the Ubuntu operating system after performing the previous operations (described earlier in this article) and how to restore this ability. The reason is the configured encryption. If you have home directory encryption configured, the swap partition is also encrypted, but with a random key. When you put the system into hibernate mode, the RAM data is stored on the swap partition and encrypted with a random key. When restoring the system from hibernation, the key that was used to encrypt the swap partition is already irretrievably lost and the system cannot read this partition. Accordingly, the data cannot be retrieved and a return to the previous state is not possible.

If you don't have partition encryption configured on your system, restoring hibernation in Ubuntu is easy. To do this, just run the commands: ls -l /home/paddy.ChPzzxqD
rm -R paddy .ecryptfs/paddy

But if the user's home partition and the swap partition are encrypted on the system, it is necessary to replace the encryption of the swap partition with a pre-selected passphrase rather than with a random key.

However, note that each user on the computer will need to know this passphrase at system boot time.

I tried this method in both cases - both on a regular Ubuntu 12.04 system and on an Ubuntu system installed on a VirtualBox virtual machine. In the latter case, there were problems with displaying the screen when restoring from sleep mode. But on a regular system everything worked fine.

Training

Enter the following command in the terminal: sudo cryptsetup status crypt swap 1

As a result, you will see a line that will indicate the device, looking something like this: /dev/sda1

or /dev/sdb5

This device is the swap partition on your system. Remember it, as you will need it later.

I always recommend doing a full backup of your data whenever you make any changes to the system. In our case, it will also be useful.

Sleep setting

Enter the following commands. Make sure you replace /dev/sdXN with your swap partition created in the "Preparation" section. When entering commands, you should strictly adhere to the specified sequence:

sudo swapoff /dev/mapper/cryptswap1
sudo cryptsetup luksClose /dev/mapper/cryptswap1
sudo cryptsetup luksFormat cipher aes cbc essiv:sha256 verify passphrase key size 256 /dev/sdXN

WARNING!
========
This will overwrite data on /dev/sda1 irrevocably.
Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
sudo cryptsetup luksOpen /dev/sdXN cryptswap1

Enter the passphrase for the /dev/sda1 device (and repeat it to avoid a typo):

sudo mk swap/dev/mapper/crypt swap 1
sudo swapon all
swapon's

The last command will display the device filename /dev/crypt swap 1 .

Open the configuration file /etc/crypttab in your preferred editor. Replace the crypt swap 1 line with the following (don't forget to change /dev/sdXN to your swap device): cryptswap1 /dev/sdXN none luks

Now edit the file /usr/share/initramfstools/scripts/local-top/cryptroot . In it, find the line (usually it has the number 288, but it can change): message "cryptsetup: unknown error setting up device mapping"

Move to the next empty line (before FSTYPE=") and insert a new line (don't forget to replace the /dev/sdXN device): /sbin/cryptsetup luksOpen /dev/sdXN crypt swap 1

Edit the file /etc/acpi/hibetnate.sh . On the first empty line, paste the value: DEVICE="/dev/mapper/crypt swap 1"

Edit the /etc/initramfstools/conf.d/resume file. Replace the existing line in it with the following: RESUME=/dev/mapper/crypt swap 1

Then edit the file /etc/polkit1/localauthoriyt/50-local.d/com.ubuntu.enable-hibernate.pkla . The file does not initially exist, so you will need to create it first. Then add the lines to it:
Identity=unixuser:*
Action=org.freedesktop.upower.hibernate
ResultActive=yes

Finally, open a terminal and enter the following command in it: sudo update initramfs u k all

Reboot.

Using sleep mode

The next time you start Ubuntu Linux, it will ask you for a new passphrase for the swap partition. Enter it and the further normal login process will continue.

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 mechanical hard drive 500 GB, dual-core AMD 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.

bitlocker

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 distinct advantages: first, 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.

Is it possible to decrypt BitLocker and TrueCrypt

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.

TrueCrypt

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.

VeraCrypt

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.

INFO

Having retired, TrueCrypt left a rich legacy: it has many forks, starting with VeraCrypt, CipherShed and DiskCryptor.

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.

CipherShed

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.

Symantec Endpoint Encryption

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 GPT support is needed and there is a desire to encrypt the system partition, then 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.

moment of truth

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:

  • Seq Q32T1 - sequential write / sequential read test, number of queues - 32, threads - 1;
  • 4K Q32T1 - random write / random read test (block size 4 KB, number of queues - 32, threads - 1);
  • Seq - sequential write / sequential read test;
  • 4K - random write / random read test (block size 4 KB);

Let's start with BitLocker. It took 19 minutes to encrypt a 28 GB partition.

Continuation of the article is available only to subscribers

Option 1. Subscribe to "Hacker" to read all the articles on the site

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 it is 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:

DiskCryptor

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:

  • there are no ways to restore access to encrypted information (if you forgot your password, you are guaranteed to lose your data);
  • only unlocking with a password is supported, the use of smart cards or biometric sensors is not possible;
  • Perhaps the biggest disadvantage of using DiskCryptor is that an attacker with administrative access to the system will be able to format the disk using standard means. Yes, he will not get access to the data, but you will lose them too.

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.

Understanding BitLocker Drive Encryption

Destination: 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 loss, theft, or improper decommissioning of 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 that do not have TPM 1.2 installed, BitLocker encryption can still be used to encrypt a Windows operating system drive. 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, that contains 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.

Checking System Integrity

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.

  • Providing a way to check the integrity of the root file and the files used in the early stages of the boot, and ensure that there are no malicious changes to those files that could be made, for example, by boot sector viruses or boot component editing tools.
  • Improved protection against software attacks when the computer is offline. Any alternative software that can start the system will not have access to the encryption keys for the Windows operating system drive.
  • System lock when replacing a file. If any of the controlled files has been replaced, the system will not start. This will alert the user to the replacement as the system will not be able to start normally. In the event of a system lockout, BitLocker encryption provides an easy recovery process.

    Hardware, firmware and software requirements

    To use BitLocker, your computer must meet certain requirements.

    • For BitLocker encryption to use the System Integrity Checking feature provided by the TPM, version 1.2 of the TPM must be installed on the computer. If you do not have a TPM installed on your computer, you will need to save the startup key to a removable device, such as a USB flash drive, when you enable BitLocker encryption.
    • The TPM-equipped computer must also have a BIOS that complies with the Trusted Computing Group (TCG) specifications. The BIOS creates a chain of trusts for pre-boot actions and must include support for the static root of the trust level measurement defined by the TCG. For a computer without a TPM module, BIOS compliance with the TCG specifications is not required.
    • The system BIOS (for both TPM and non-TPM computers) must support the USB mass storage class, including reading small files from a USB flash drive in a pre-operating system environment. For more information about USB, see the USB Mass Storage Device Specification and UFI Mass Storage Commands on the USB website (http://go.microsoft.com/fwlink/?LinkId=83120).
    • The hard disk must be divided into at least two disks.
      • The operating system drive (or boot drive) contains the operating system and the files it needs to run and must be formatted with the NTFS file system.
      • The system disk contains the files needed to boot Windows after the BIOS has loaded the platform. BitLocker encryption is not enabled for this drive. For BitLocker encryption to work, the system drive must not be encrypted, it must not be an operating system volume, and it must be formatted with the NTFS file system. The system drive must be at least 1.5 gigabytes (GB) in size.

    Installation and initialization

    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:

    1. On computers with a TPM, initialize the TPM using the TPM Install Wizard, a Control Panel component BitLocker Drive Encryption, or by executing a script designed to initialize the module.
    2. Set up BitLocker encryption. Open the BitLocker Encryption Configuration Wizard from the Control Panel, which will guide you through the setup process and provide you with the option to configure advanced authentication settings.

    When initializing BitLocker encryption, the local administrator must 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).

    Corporate implementation

    BitLocker encryption can use an organization's existing Active Directory Domain Services (AD DS) infrastructure to store recovery keys offsite. 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).

    Recycle and reuse your computer

    annotation

    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 of RAM. 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.

    Introduction

    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 hard drive encryption systems, in the event 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.

    Attacks on encrypted drives

    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 disclosures 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

    BitLocker is a system included with some versions of Windows Vista. It functions as a driver between the file system and the hard disk driver, 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 addition procedure is performed on the plaintext 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, since 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).

    File Vault

    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 a user password is entered, a header is decrypted containing the AES key and a second K2 key 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 that the data has not been corrupted, the 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 with 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. Account passwords are often used to protect keys, which in turn can be used to protect passphrases on FileVault encrypted drives.

    TrueCrypt

    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).

    Dm-crypt

    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 it is restored, 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.

    Protection methods and their limitations

    The implementation of protection against attacks on RAM is not trivial, since the cryptographic keys used must be stored somewhere. We propose to focus on destroying or hiding 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 life of the data in the RAM.

    Memory overwrite

    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.

    Restricting downloads from the network or from removable media

    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, an attacker can change the hard drive itself, or in many cases, reset the computer's NVRAM to revert to the original BIOS settings.

    Safe Sleep

    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.

    Rejection of precalculations

    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.

    Key expansion

    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 that is not currently in use 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, approx. 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 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.

    Physical protection

    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.

    Change of architecture

    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.

    Trusted Computing

    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.

    conclusions

    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.


Author: Paddy Landau
Publication date: September 2012
Translation: Semenenko V.
Date of publication of the translation: November 13, 2012

When you install the Ubuntu operating system, you may not think about setting up data encryption in it. Or there may be a situation where you add a user to the system without encrypting his home directory. But now you have changed your mind and decided to configure the protection of this directory. In other words, you (or another user on the computer) want a feature that doesn't currently exist...

Creating an Encrypted Partition in Ubuntu

How can you add encryption capability to an already installed Ubuntu Linux system?

Luckily, it's fairly easy to implement. To do this, just follow three basic steps:

  • create an encrypted copy of your home directory;
  • delete the original unencrypted home directory;
  • encrypt the swap partition (performed only once, when installing an Ubuntu system or when following this guide step by step).

The steps in this article were performed on a fully updated Ubuntu Precise 12.04 system.

Training

Due to a current bug in Ubuntu Linux, you cannot log in if the login graphic is in the user's encrypted home folder. If the user has changed the default appearance, make sure that it is also not located in the user's home folder.

Creating an encrypted copy of the user's home directory is a secure procedure. However, it is worth paying attention that a certain amount of hard disk space is required for its implementation. If it turns out that there is too little space, you need to back up the data, then delete all large files (for example, movies) from it and restore them from this backup after encryption is completed. I generally recommend that you back up all your data to prevent possible problems.

Using your preferred package manager, install the encrypt-utils program.

Encryption

In this tutorial, I will use paddy's login as the username to act on. You need to replace it with the name of the user whose home directory will be encrypted.

Reboot Ubuntu Linux and go into "Recovery Mode". A word of advice - while the system boots up, press and hold the Shift key to open the Grub menu. Usually the line "Recovery Mode" (Recovery Mode) is located second from the top in the list of this bootloader.

From the recovery mode menu, select "Drop" to display the command line prompt for the root account.

To fix the programming error mentioned at the beginning of this article, enter the following two commands:

Mount --options remount,rw / mount --all

Now we can create an encrypted copy of the paddy user's home directory. To do this, enter the command below. At the same time, take the trouble to remember your own password, as this utility will require it to complete the operation:

cryptfs-migrate-home --user paddy

When the encryption process is complete, you will see several warnings. You can ignore them. But you will need to remember the path to the temporary folder created by this command. Its appearance will be something like this:

/home/paddy.ChPzzxqD

In this case, the last eight characters (after the dot) are a random set. You will need this directory in the next "Complete" or "Return to Initial State" steps, which will be discussed later.

Reboot your Ubuntu Linux system. To do this, enter the command:

Reboot now

It may take a few seconds after typing and running the command, so be patient.

Completion

Log in to your Ubuntu system in the usual way, as you did every time. Check that everything works as before.

If something is wrong, you can immediately go to the "Return to the original state" item.

If everything in the system works fine, completed the final steps.

Open the terminal and enter the command to delete the temporary directory. To do this, you will need to remember the path to the temporary folder that was created when the home directory was encrypted.

Sudo rm -R /home/paddy.ChPzzxqD

Restore the data that you deleted (if any) in the "Preparation" step.

Open the terminal again and enter the command to encrypt the swap partition. If you previously had a user with home directory encryption configured, you can safely skip this step:

sudo ecryptfs-setup-swap

Reboot again.

Return to original state

If the encryption process failed, you will need to repeat the previous steps again.

Run commands:

Mount --options remount,rw / mount --all ecryptfs-migrate-home --user paddy

Then enter the command to view the contents of the temporary folder created during the encryption process. To do this, you again need to remember the path to it. This should not generate any errors. If they do, then you need help.

ls -l /home/paddy.ChPzzxqD

Now complete the reset process by issuing three commands:

Cd /home rm -R paddy .ecryptfs/paddy mv paddy.ChPzzxqD

Reboot again.

Hope the above steps helped you. If you have unresolvable problems, you can post a request on my Ubuntu forum thread:

Sleep mode when encrypted

Most users often wonder why there is no hibernation (hibernate) in the Ubuntu operating system after performing the previous operations (described earlier in this article) and how to restore this ability. The reason is the configured encryption. If you have home directory encryption configured, the swap partition is also encrypted, but with a random key. When you put the system into hibernate mode, the RAM data is stored on the swap partition and encrypted with a random key. When restoring the system from hibernation, the key that was used to encrypt the swap partition is already irretrievably lost and the system cannot read this partition. Accordingly, the data cannot be retrieved and a return to the previous state is not possible.

If you don't have partition encryption configured on your system, restoring hibernation in Ubuntu is easy. To do this, just run the commands:

ls -l /home/paddy.ChPzzxqD rm -R paddy .ecryptfs/paddy

But if the user's home partition and the swap partition are encrypted on the system, it is necessary to replace the encryption of the swap partition with a pre-selected passphrase rather than with a random key.

However, note that each user on the computer will need to know this passphrase at system boot time.

I tried this method in both cases - both on a regular Ubuntu 12.04 system and on an Ubuntu system installed on a VirtualBox virtual machine. In the latter case, there were problems with displaying the screen when restoring from sleep mode. But on a regular system everything worked fine.

Training

Enter the following command in the terminal:

sudo cryptsetup status crypt swap 1

As a result, you will see a line in which the device will be designated, looking something like this:

/dev/sda1

/dev/sdb5

This device is the swap partition on your system. Remember it, as you will need it later.

I always recommend doing a full backup of your data whenever you make any changes to the system. In our case, it will also be useful.

Sleep setting

Enter the following commands. Make sure you replace /dev/sdXN with your swap partition created in the "Preparation" section. When entering commands, you should strictly adhere to the specified sequence:

sudo swapoff /dev/mapper/cryptswap1 sudo cryptsetup luksClose /dev/mapper/cryptswap1 sudo cryptsetup luksFormat cipher aes cbc essiv:sha256 verify passphrase key size 256 /dev/sdXN WARNING! ======== This will overwrite data on /dev/sda1 irrevocably. Are you sure? (Type uppercase yes): YES Enter LUKS passphrase: Verify passphrase: sudo cryptsetup luksOpen /dev/sdXN cryptswap1

Enter the passphrase for the /dev/sda1 device (and repeat it to avoid a typo):

sudo mk swap /dev/mapper/crypt swap 1 sudo swapon --all swapon -s

The last command will display the device filename /dev/crypt swap 1 .

Open the configuration file /etc/crypttab in your preferred editor. Replace the crypt swap 1 line with the following (don't forget to change /dev/sdXN to your swap device):

Cryptswap1 /dev/sdXN none luks

Now edit the file /usr/share/initramfstools/scripts/local-top/cryptroot . In it, find the line (usually it has the number 288, but it can change):

Message "cryptsetup: unknown error setting up device mapping"

Move to the next empty line (before FSTYPE=") and insert a new line (don't forget to replace the /dev/sdXN device):

/sbin/cryptsetup luksOpen /dev/sdXN crypt swap 1

Edit the file /etc/acpi/hibetnate.sh . On the first empty line, paste the value:

DEVICE="/dev/mapper/crypt swap 1"

Edit the /etc/initramfstools/conf.d/resume file. Replace the existing line in it with the following:

RESUME=/dev/mapper/crypt swap 1

Then edit the file /etc/polkit1/localauthoriyt/50-local.d/com.ubuntu.enable-hibernate.pkla . The file does not initially exist, so you will need to create it first. Then add the lines to it:

Identity=unixuser:* Action=org.freedesktop.upower.hibernate ResultActive=yes

Finally, open a terminal and enter the following command in it:

Sudo update initramfs u k all

Reboot.

Using sleep mode

The next time you start Ubuntu Linux, it will ask you for a new passphrase for the swap partition. Enter it and the further normal login process will continue.

If you suddenly forgot the passphrase, enter something. After three failed attempts the system will continue the login process anyway, but without mounting the swap partition. To get a new keyword, follow the step-by-step instructions described in this article again.

You will now find the "Hibernate" mode in the Ubuntu Linux shutdown menu and can use it. If you want to enter sleep mode from the command line, just type the following command in the terminal.

Using cloud drives, users are increasingly interested in encryption in linux distributions. I will introduce you to an interesting "encrypting cloud" program.

Have you ever thought that purely theoretically, those files that you store in cloud storage, purely technically, can become public in a matter of minutes under certain circumstances. Personally, I am not, and with all the lack of paranoia characteristic of me, I post this information exclusively for those who are “already herded by ZOG”, because as the old joke said: “If you are not paranoid, this does not mean that you are not being persecuted.” So follow me. friends.

Linux implements disk encryption in various ways and at various levels. There are hundreds of ways to encrypt an entire disk. I’ll just show the work of the program I like, which even a noob like me can figure out. This app is called Cryptomator.

What did I like about it:

  • It works perfectly and instantly with Google Drive, Yandex Disk, OneDrive, Mail.ru Cloud, Dropbox, ownCloud, Nextcloud, and, in general, with any cloud storage service that can synchronize with a local directory;
  • is an open source application, which indicates the possibility of checking for backdoors and other things.
  • performs AES encryption with a length of 256 bits;
  • open source meaning no backdoors;
  • encrypts filenames and obfuscates the folder structure;
  • can be used locally, no internet connection required.

In fact, encryption takes place on a local computer, and then synchronized with the cloud, so even if someone gets access to your cloud storage, they will see a set of files and folders with an abracadabra name and the same content.

I liked this application for two reasons, the first is an interesting and convenient implementation of connecting encrypted containers like a virtual hard disk. Implemented by the type of USB drive connection. And the second is cross-platform, the cryptomator is available for Linux, Windows and Mac OS. That is, if you have Linux at home, Mac OS at work, and Windows at your leisure, then you can easily access your cloud encrypted files by simply installing Cryptomator and entering your password in it.

Installing Cryptomator - an application that encrypts files and folders in Linux

To install on Ubuntu and derivatives, type in the terminal:

#add repository sudo add-apt-repository ppa:sebastian-stenzel/cryptomator #update rep package lists sudo apt-get update #directly install Cryptomator sudo apt-get install cryptomator

Installation on Arch Linux and its derivatives is as easy as ever

Yaourt -S cryptomator #I won't write about pacaur and so it's clear

Installation in Fedora, Centos and other rpm distributions is done by simply downloading a binary rpm package and actually installing it.
Download rpm package

Using Cryptomator

This is how the creation of a new repository looks like


Selecting the directory in which the encrypted directory will be created

This directory can be either local or a synced directory in your cloud storage.


We create a strong key, which we will use in the future to connect our encrypted storage.


After that, it remains only to enter the newly created key and the encrypted partition is mounted.


In the screenshot above, I threw a package with 536.9 megabyte files into the mounted cipher folder and it worked out this bunch of small files for me in 1 minute.