Disk encryption in Linux. Using Cryptomator to encrypt a cloud disk in Linux Hardware, firmware and software requirements

There are many reasons to encrypt the data on your hard drive, but the price for data security will be a decrease in system speed. The purpose of this article is to compare performance when working with a disk encrypted with different means.

To make the difference more dramatic, we chose not a super-modern car, but an average one. A regular mechanical hard drive of 500 GB, dual-core AMD at 2.2 GHz, 4 gigs 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.

I chose CrystalDiskMark to evaluate performance. As for the encryption tools I tested, I settled on the following list: BitLocker, TrueCrypt, VeraCrypt, CipherShed, Symantec Endpoint Encryption and CyberSafe Top Secret.

BitLocker

This is a standard disk encryption facility 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, it’s correct. On the other hand, the code is closed, and there is no certainty that it did not contain backdoors for the FBI and other interested parties.

Disk encryption is carried out 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, the key can be obtained immediately from it or after authentication. You can log in using the key on the flash drive or by entering the PIN code from the keyboard. Combinations of these methods give many options for limiting access: simply TPM, TPM and USB, TPM and PIN, or all three at once.

BitLocker has two undeniable advantages: firstly, it can be managed through group policies; Secondly, it encrypts volumes, not physical disks. This allows you to encrypt an array of multiple drives, something that some other encryption tools cannot do. BitLocker also supports 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 the MBR format. This is not required with BitLocker.

In general, there is only one drawback - closed source. If you're keeping secrets from people in your household, BitLocker is perfect. 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 program called Elcomsoft Forensic Disk Decryptor, suitable for decrypting BitLocker, TrueCrypt and PGP drives. As part 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 perfectly decrypted EFS folders, but provided that the user password was not set. If you set the password to even 1234, the program was powerless. In any case, I was unable to decrypt an encrypted EFS folder belonging to a user with 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 refuse support for his brainchild.

There are only grains of information that do not allow us to put the puzzle together. Thus, in 2013, fundraising began to conduct an independent audit of TrueCrypt. The reason was information received from Edward Snowden about the deliberate weakening of TrueCrypt encryption tools. Over 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 was completed, TrueCrypt again found itself at the center of a scandal. ESET specialists published a report that the Russian version of TrueCrypt 7.1a, downloaded from truecrypt.ru, contained malware. Moreover, the site truecrypt.ru 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.

The advantages of TrueCrypt include open source, the reliability of which is now supported by independent audit, and support for dynamic Windows volumes. Disadvantages: the program is no longer being 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, which only supports AES, TrueCrypt also includes 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 won’t repeat it.

VeraCrypt

The most advanced TrueCrypt clone. It has its own format, although it has the ability 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 significantly more resistant to brute force attacks, but also significantly reduces the performance of working with such a partition. How significant we will soon find out.

Among the advantages of VeraCrypt is its open source code, as well as its own and more secure format of virtual and encrypted disks compared to TrueCrypt. The disadvantages are the same as in the case of the progenitor - lack of UEFI/GPT support. It is still impossible to encrypt the system GPT disk, but the developers claim that they are working on this problem and such encryption will soon be available. But they’ve been working on this for two years now (since 2014), and when there will be a release with GPT support and whether there will be one at all is not yet known.

CipherShed

Another TrueCrypt clone. Unlike VeraCrypt, it uses the native TrueCrypt format, so you can expect its performance to be close to that of TrueCrypt.

The advantages and disadvantages are still the same, although you can add the impossibility to the disadvantages TrueCrypt installations and CipherShed on the same computer. 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 cope with the task.

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. This is what we will consider. The program, of course, is proprietary, the sources are closed, and one license costs 64 euros. But there is support for GPT, but only starting from Windows 8.

In other words, if you need GPT support and want to encrypt the 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 also wants to install IIS 6.0. Isn't it a lot of good stuff for one disk encryption program? We went through all this just to measure performance.

Moment of truth

So, let's get to the fun part, namely testing. The first step is to check the performance of the disk without encryption. Our “victim” will be a 28 GB hard drive partition (regular, not SSD), formatted as NTFS.

Open CrystalDiskMark, select the number of passes, the size of the temporary file (we will use 1 GB in all tests) and the disk itself. It is worth noting that the number of passes has virtually no effect on the results. The first screenshot shows the results of measuring disk performance without encryption with the number of passes 5, the second - with the number of passes 3. As you can see, the results are almost identical, so we’ll 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.

The continuation of the article is available only to subscribers

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

Subscription will allow you to read ALL paid materials on the site, including this article, for the specified period. We accept payments by bank cards, electronic money and transfers from mobile operator accounts.

The privacy and security requirements of a computer are entirely determined by the nature of the data stored on it. It’s one thing if your computer serves as an entertainment station and there is nothing on it except a few toys and a daddy with photos of your favorite cat, and quite another thing 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 login password, which is requested every time you turn on the computer.

The next level of protection is access rights at the file system level. A user who does not have permission privileges will receive an error when attempting to access files.

However, the described methods have one extremely significant drawback. They both work at the same level operating system and they 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 you use the achievements of cryptography and securely use them. Below we will look at two methods of such protection.

The first method considered today will be Microsoft's built-in crypto protection. Encryption, called BitLocker, first appeared in Windows 8. It cannot be used to secure an individual folder or file; only encryption of the entire disk 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), and 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, use the following instructions:

The undoubted advantage of this utility compared to the BitLocker mechanism is that it can be used on systems released before Windows 8 (even Windows XP, which has been discontinued, is supported). But DiskCryptor also has several significant disadvantages:

there are no ways to restore access to encrypted information (if you forget your password, you are guaranteed to lose your data);
Only password unlocking 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 gain access to the data, but you will also lose it.

To summarize, I can say that if your computer has an OS installed 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

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. Integrating BitLocker into the operating system counters the threat of data theft or vulnerability by protecting against lost, stolen, or improperly decommissioned computers.

Data on a lost or stolen computer is vulnerable to unauthorized access, either through a hacking tool or by connecting the computer's hard drive to another computer. BitLocker encryption helps prevent unauthorized access to your data, increasing file and system security. BitLocker encryption also helps keep data inaccessible when BitLocker-protected computers are decommissioned or reused.

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 is turned off.

On computers without TPM 1.2 installed, BitLocker encryption can still be used to encrypt the Windows operating system drive. But this implementation would require the user to insert a USB startup key to start the computer or wake it from sleep mode, and does not provide the pre-startup system integrity check provided by BitLocker TPM encryption.

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 the startup key. These additional security measures provide multi-factor authentication and ensure that the computer will not start or wake up until the correct PIN or startup key is provided.

System integrity check

BitLocker encryption can use the Trusted Platform Module to verify the integrity of boot components and boot configuration data. This helps ensure that when BitLocker encryption is used, the encrypted drive is accessible only if these components have not been tampered with and the encrypted drive is installed on the original computer.

BitLocker encryption helps ensure the integrity of the startup process by doing the following:

Provide a way to verify the integrity of the root file and files used during the early stages of boot, and to ensure that there are no hostile 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 run the system will not have access to the encryption keys for the Windows operating system disk.
System locks when replacing a file. If any of the monitored files have 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. If your system is locked, BitLocker encryption ensures a simple recovery process.
Hardware, firmware and software requirements

To use BitLocker, your computer must meet certain requirements.
- For BitLocker to use the system integrity verification capability provided by the Trusted Platform Module, version 1.2 of the module must be installed on the computer. If you do not have a TPM installed on your computer, you will need to store the startup key on a removable device, such as a USB flash drive, when you enable BitLocker encryption.
- The computer with the TPM must also have a BIOS that meets Trusted Computing Group (TCG) specifications. The BIOS creates a chain of trust for actions before the operating system boots and must include support for the static root trust measurement object defined by the TCG. For a computer without a TPM, the BIOS does not need to comply with the TCG specifications.
- The system BIOS (for computers with or without a TPM) must support the USB mass storage device class, including reading small files from a USB flash memory device in a pre-operating system startup environment. For more information about USB, see the storage device specifications. USB devices and UFI storage device commands on the USB website (http://go.microsoft.com/fwlink/?LinkId=83120).
- The hard drive must be divided into at least two disks.
  - The operating system disk (or boot disk) contains the operating system and the files needed to run it, and must be formatted with the NTFS file system.
  - The system drive contains the files needed to boot Windows after the BIOS boots 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 disk capacity must be at least 1.5 gigabytes (GB).
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 Control Panel or by right-clicking the drive in File Explorer.

At any time after installing and initially configuring the operating system, an administrator can use the BitLocker Setup Wizard to initialize BitLocker encryption. The initialization process consists of two stages:
1. On computers with a TPM, initialize the latter using the TPM Installation Wizard, a component of Control Panel BitLocker Drive Encryption, or by executing a script designed to initialize the module.
2. Set up BitLocker encryption. From Control Panel, open the BitLocker Setup Wizard, which walks you through the setup process and gives you the option to configure additional authentication settings.
When initializing BitLocker encryption, the local administrator 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 the BitLocker-protected 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 leverage an organization's existing Active Directory Domain Services (AD DS) infrastructure to store recovery keys remotely. BitLocker encryption provides a wizard for configuration and management, as well as extensibility and management capabilities through a scriptable WMI interface. In addition, BitLocker encryption provides a recovery console built into the boot process to allow the user or support personnel to regain access to a locked computer.

For more information about writing scripts for BitLocker encryption, see Win32_EncryptableVolume (http://go.microsoft.com/fwlink/?LinkId=85983).

Decommissioning and reusing a computer

annotation
Contrary to popular belief, DRAM memory, used in most modern computers, stores data even after the power is turned off for several seconds or minutes, and this happens at room temperature and even if the chip is removed from the motherboard. This time is quite enough to take a complete RAM dump. We will show that this phenomenon allows an attacker with physical access to the system to bypass the OS functions to protect cryptographic key data. We will show how rebooting can be used to successfully attack known hard drive encryption systems without using any specialized hardware or materials. We will experimentally determine the degree and probability of retention of residual magnetization and show that the time for which data can be taken can be significantly increased using simple techniques. New methods will also be proposed for searching for cryptographic keys in memory dumps and correcting errors associated with loss of bits. Several ways to reduce these risks will also be discussed, but we do not know of a simple solution.
Introduction
Most experts assume that data from a computer's RAM is erased almost instantly after the power is turned off, or they believe 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 series of attacks that, using the remanence effects of DRAM, will allow us to recover encryption keys stored in memory. This poses a real threat to laptop users who rely on hard drive encryption systems. After all, if an attacker steals a laptop while the encrypted disk is connected, he will be able to carry out one of our attacks to access the content, 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, if an attacker has physical access to the computer, any important information stored in RAM can become a target for attack. It is likely that many other security systems are vulnerable as well. For example, we discovered that Mac OS X leaves account passwords in memory, from where we were able to extract them, and we also carried out attacks to obtain the private RSA keys of the Apache web server.
While some in the information security and semiconductor physics communities were already aware of the remanence effect in DRAM, 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 information security implications of these phenomena.
Attacks on encrypted drives
Encrypting hard drives is a well-known method of protecting 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, that’s what they are for, editor’s note). A California state law passed in 2002 requires reporting of possible disclosures of personal data only if the data was not encrypted, because. It is believed that data encryption is a sufficient protective measure. Although the law does not describe any specific technical solutions, many experts recommend the use of encryption systems for hard drives or partitions, which will be considered sufficient protection measures. The results of our research showed that faith in disk encryption is unfounded. A less-than-skilled attacker can bypass many commonly used encryption systems if a laptop with data is stolen while it is turned on or in sleep mode. And data on a laptop can be read even if it is on an encrypted drive, so using hard drive encryption systems is not a sufficient measure.
We used several types of attacks on well-known hard drive encryption systems. What took the most time was installing encrypted disks and checking the correctness of the detected encryption keys. 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 similar attacks.
BitLocker
BitLocker is a system included in some versions of Windows Vista. It functions as a driver that runs between the file system and the hard drive driver, encrypting and decrypting selected sectors on demand. The keys used for encryption remain in RAM as long as the encrypted disk is encrypted.
To encrypt each sector of a hard drive, BitLocker uses the same pair of keys created 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, the procedure is carried out binary addition plaintext with a session key generated by encrypting the sector offset byte with the sector encryption key. The resulting data is then processed by two mixing functions that use the Microsoft-developed Elephant algorithm. These keyless functions are used to increase the number of changes to all cipher bits 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, which 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 onto an external drive, used the keyfind program to search for possible keys, tried all the suitable options (pairs of sector encryption key and 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 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 any software. In the Microsoft documentation, the BitLocker system is described 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 in this class is the way keys are stored when the encrypted drive is disconnected. By default, in basic mode, BitLocker protects the master key only using the TPM module, which exists on many modern PCs. This method, which appears to be widely used, is particularly vulnerable to our attack because it allows encryption keys to be obtained 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 (before login window) without entering any authentication information.
Apparently, Microsoft specialists are familiar with this problem and therefore recommend configuring BitLocker in an improved mode, where keys are protected not only using TPM, but also with a password or key on an external USB drive. But, even in this mode, the system is vulnerable if an attacker gains physical access to the PC at the moment when it is working (it can even be locked or in sleep mode (states - simply turned off or hibernate in this case are considered not susceptible to this attack).
FileVault
Apple's FileVault system has been partially investigated and reverse engineered. In Mac OS X 10.4, FileVault uses a 128-bit AES key in CBC mode. When the user password is entered, the header containing the AES key and the 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 RAM imaging program to retrieve data from an Intel-based Mac with a FileVault-encrypted drive attached. After this, the keyfind program automatically found FileVault AES keys without errors.
Without an initialization vector, but with the resulting AES key, it becomes possible to decrypt 4080 of the 4096 bytes of each disk block (all except the first AES block). We made sure that the initialization vector is also in the dump. Assuming that the data has not yet become corrupted, an attacker can determine the vector by trying all the 160-bit strings in the dump one by one and checking whether they can form a possible plaintext when binary added 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 discovered that Mac OS X 10.4 and 10.5 leave multiple copies of the 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
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 XTS mode. TrueCrypt stores the encryption key and tweaks the key in the partition header on each drive, which is encrypted with a different key derived from the user-entered password.
We tested TrueCrypt 4.3a and 5.0a running on Linux. We connected the drive, encrypted with a 256-bit AES key, then removed 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 tweak key of the XTS mode.
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 AES key schedule. In our dump, the LRW key was not corrupted. (If errors occurred, 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 a variety of algorithms and modes, but by default it uses a 128-bit AES cipher in CBC mode with IVs generated not based on key information.
We tested the partition created by dm-crypt 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 briefly turned off the power and, using a modified PXE bootloader, took a memory dump. The keyfind program detected a correct 128-bit AES key, which was recovered without any errors. After it is restored, the 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.
Methods of protection and their limitations
Implementing protection against attacks on RAM is non-trivial, since the cryptographic keys used must be stored somewhere. We suggest focusing efforts on destroying or hiding keys before an attacker can gain physical access to the PC, preventing RAM dump software from running, physically protecting RAM chips, and reducing the lifespan of RAM data when possible.
Overwriting memory
First of all, you should whenever possible avoid storing keys in RAM. You need to overwrite key information when it is no longer used and prevent data from being copied to page files. Memory must be cleared in advance using OS tools or additional libraries. Naturally, these measures will not protect keys currently in use, since they must be stored in memory, such as keys 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 at boot using a cleanup tool. POST request(Power-on Self-Test) before loading the OS. If an 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 remove the RAM chips and insert them into another PC with the BIOS settings he needs.
Restricting downloading from the network or from removable media
Many of our attacks were carried out using downloads over the network or from 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 roll back to the original BIOS settings.
Safe Sleep Mode
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 you must enter a password) does not protect the contents of RAM. Hibernation mode is also not effective if the PC is locked when returning from sleep mode, since an attacker can activate the return from sleep mode, then reboot the laptop and take a memory dump. The hibernate mode (the contents of RAM are copied to the hard drive) will also not help, except in cases of using key information on alienated media to restore normal functioning.
In most hard drive encryption systems, users can protect themselves by turning off the PC. (The Bitlocker system in the basic mode of operation of the TPM module remains vulnerable, since the disk will be connected automatically when the PC is turned on). Memory contents may persist for a short period after being disconnected, so it is recommended to monitor your workstation for a couple more minutes. Despite its effectiveness, this measure is extremely inconvenient due to the long loading time of workstations.
The transition to sleep mode can be secured in the following ways: require a password or other secret to “wake up” the workstation and encrypt the memory contents with a key derived from this password. The password must be strong, since an attacker can make a memory dump and then try to guess the password by brute force. If encrypting the entire memory is not possible, you need to encrypt only those areas that contain key information. Some systems may be configured to enter this type of protected sleep mode, although this is not usually the default setting.
Avoiding Pre-Computations
Our research has shown that using precomputation to speed up cryptographic operations makes key information more vulnerable. Pre-calculations result in redundant information about key data appearing in memory, which allows an attacker to recover keys even if there are errors. For example, as described in Section 5, information about the iterative keys of the AES and DES algorithms is extremely redundant and useful to an attacker.
Not doing pre-computations will reduce performance because potentially complex calculations will have to be repeated. But, for example, you can cache precomputed values for a certain period of time and erase the received data if it is not used during this interval. This approach represents a trade-off 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 it more difficult to recover the key due to various errors. This method has been discussed in theory, where a discovery-resistant function has been shown whose inputs remain hidden even if virtually all of the outputs have been discovered, much like 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, editor's note), where H is a hash function, such as SHA-256.
Now imagine that the power was turned off, this would cause the d bits in this area to be changed. If the hash function is strong, when attempting to recover key K, the attacker can only count on being able to guess which bits of area B were changed out of the approximately half that could have changed. If d bits have been changed, the attacker will have to search an area of size (B/2+d)/d to find the correct values of R and then recover key K. If area B is large, such a search can be very long, even if d is relatively small
In theory, we could store all the keys this way, calculating each key only when we need it, and deleting it when we don't need it. Thus, using 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, memory modules are located in a closed PC case, or are sealed with epoxy glue to prevent attempts to remove or access them. You can also implement memory erasure 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-resistant hardware (such as the IBM 4758 coprocessor) and can greatly increase the cost of the workstation. On the other hand, using memory soldered to the motherboard will be much cheaper.
Architecture change
You can change the PC architecture. This is impossible for already used PCs, but will allow you to secure new ones.
The first approach is to design DRAM modules so that they erase all data faster. This can be tricky because the goal of erasing data as quickly as possible conflicts with the other goal of keeping data from going missing between memory refresh periods.
Another approach is to add key information storage hardware that is guaranteed to erase all information from its storage upon startup, restart, and shutdown. This way, we will have a secure place to store multiple keys, although the vulnerability associated with their pre-calculation will remain.
Other experts have proposed an architecture in which the contents of memory would be permanently encrypted. If, in addition to this, we implement erasing of keys during a 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. Although useful in protecting against some attacks, in its current form such equipment does not help prevent the attacks we describe.
The TPM modules used do not implement full encryption. Instead, they observe the boot process to decide whether it is safe to load 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 as expected. But as soon as the key is in RAM, it immediately becomes a target for our attacks. TPMs can prevent a 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 allows for a whole class of attacks that can obtain sensitive data, such as encryption keys, from RAM, despite the OS's attempts to protect its contents. The attacks we have described can be implemented 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 private keys necessary to create SSL sessions. Our key information search techniques are likely to be effective for finding passwords, account numbers, and any other sensitive information stored in RAM.
It looks like there is no easy way to fix the vulnerabilities found. The software change will most likely not be effective; hardware changes will help, but the time and resource costs will be high; Trusted computing technology in its current form is also ineffective because it cannot protect keys located in memory.
In our opinion, laptops that are often in and operating in modes vulnerable to these attacks are most susceptible 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

This is the only reliable way to protect information in conditions where physical access to the computer is possible for unauthorized people. A password to start any operating system - Windows, Linux or Mac OS - can only save you from children. Any specialist can bypass password protection in a couple of minutes - about the same amount of time it takes to insert a flash drive into a computer and load your operating system from it.

But encrypted data is much more difficult to open. Or even impossible without a digital key or passphrase. Of course, there are different encryption algorithms and within these algorithms there are different parameters- all this affects the resistance to hacking. When using weak algorithms or vulnerable parameters, you can gain access to encrypted files and folders. But in general, we can assume that encryption is reliable data protection.

The most common way to protect data is file encryption. An encrypted folder is created on the disk and files are written to it. Theoretically, this is reliable if the AES algorithm is used, the keys are long. But there remains an unobvious vulnerability of data with this encryption method. The fact is that the operating system remains unprotected. And this gives the attacker the opportunity to install a special program on the system (keylogger, rootkit) which will be launched when the OS starts and monitor the user’s actions, and thus sooner or later the attacker will receive a password or key file to access encrypted folders and files. Or it will be able to obtain this data itself after the user opens the encrypted file.

This means that truly strong data protection on a disk involves encrypting not individual files and folders, but the entire partition. Moreover, for reliable protection, encryption of the entire disk is necessary. Nothing should remain “on the surface”. This article will provide instructions on how to create an encrypted system partition and disk in Linux Ubuntu.

The encrypted file system in Linux is supported at the operating system kernel level. That is, there is no need to look for any fancy cryptographic programs and, moreover, the use of encrypted Linux partitions is transparent - the user does not need to know anything about encryption and does not need to do anything to encrypt their files and folders.

In order to create a reliable encrypted system for Linux, you need to understand which parts of this system need to be protected. There are four of them:

System area - denoted as root or / .
Boot area - denoted as /boot root in the form of a folder.
User data area - denoted as /home. Can be located on a separate partition or on a partition root in the form of a folder.
Virtual memory area - denoted as swap. Most often located on a separate partition, but can be located on a partition root as a file.

All these areas need to be protected.

The article will discuss a simplified configuration - swap And /boot on separate sections, and root And /home combined on one section. But for more complex cases, the protection technology will be the same.

With area encryption root, swap And /home there are no difficulties, but with protection /boot There is a problem. The fact is that from this area the system bootloader launches the initrd and the Linux kernel. If this area is encrypted, then the bootloader will not be able to start the kernel and, accordingly, starting the OS will be impossible. That is, encrypt /boot it is impossible, but it is also impossible to leave it open, because in this case it will be possible to replace the kernel with another one containing malicious code that will intercept the password for decrypting the disk..

The solution is to place a section /boot on removable media, on a flash drive. The flash drive will be a kind of electronic key to the system. Without it, running the OS from an encrypted disk will be impossible. That is, partition protection /boot carried out at the physical level - by removing it from the computer.

Thus, the general protection scheme is as follows:

Sections root, swap And /home located on a fully encrypted hard drive.
Chapter /boot located on removable media.

The encrypted Ubuntu installation will be performed using Ubuntu Live. Why Live? After all, the Alternate distribution allows you to do the same without dancing with a tambourine, there are encryption options in the installer. Personally, I don’t like the fact that Alternate is exclusively an installation distribution; it cannot be used in any other way - neither for diagnostics nor for work. In addition, the Alternate installer works in the console, and this is somehow archaic in the 21st century. So Live.

This instruction applies to two LTS releases 10.04 and 12.04, in both cases everything is done the same way. Although tested in practice only on these two releases, it should also work on others.

After downloading to Live, you will need an Internet connection, because Live releases do not have the lvm2 package - you will have to download and install it. So, the instructions are step by step.

Installing LVM

Establish an Internet connection. Then run two commands:

sudo apt-get update
sudo apt-get install lvm2

You can download in advance, write to a flash drive or disk the libdevmapper-event, lvm2, watershed packages and then install them with the dpkg command. But the Internet will still be required at the final stage.

Preparing the hard drive and flash drive

You need to create one empty partition on your hard drive that is not partitioned into the file system. The disk format can be MS-DOS or GPT - it doesn't matter. This section will serve as a crypto container.

You also need to create one partition on the flash drive, but with file system Ext3.

Encrypting the system disk

Encrypting an entire partition on a hard drive is done with the command:

sudo cryptsetup --cipher aes-xts-plain --key-size 512 --verify-passphrase luksFormat /dev/sda1

Important note.

This command will issue a request and to confirm it you need to enter the word YES, exactly like that, in capital letters. This request is made to make sure that your keyboard is set to English! After this, you will need to enter the passphrase twice. This phrase should be long and should not contain frequently repeated characters. Ideally, this should be a random set of letters and numbers. It is better to come up with this phrase in advance, even before starting work on creating the system.

When entering a key phrase, no characters will be displayed in the terminal, so you need to type carefully. But the phrase will be requested twice, so if you make a mistake, the program will report it.

After successfully creating a crypto container, for further work you need to connect this encrypted disk:

sudo cryptsetup luksOpen /dev/sda1 crypted

This command will prompt you for the passphrase that was entered in the previous command.

Creating encrypted partitions

The next stage is the creation of encrypted sections inside the LUKS crypto container. The LVM mechanism is used to create these partitions.

sudo pvcreate /dev/mapper/crypted
sudo vgcreate ubuntu /dev/mapper/crypted
sudo lvcreate -L 2600M -n swap ubuntu
ssudo lvcreate -l 100%FREE -n root ubuntu
sudo mkswap /dev/mapper/ubuntu-swap
sudo mkfs.ext3 /dev/mapper/ubuntu-root

Note.

The size of the swap partition should be approximately 30% larger than the size of the RAM. The root partition is at least 5-7 Gigabytes.

Installing Ubuntu on an encrypted drive

After creating the encrypted partitions, you need to run the installer, the shortcut for which is on the desktop. The installation is normal, it is only important to unmount the flash drive where /boot will be written before running the installer, and correctly specify the partitions for installation.

You must answer "Yes" to this request. This is a flash drive where you will need to install the /boot partition. This request will be issued if you forget to unmount the flash drive before running the installer.

And connect the sections like this:

Encrypted partitions for Ubuntu installations this is /dev/mapper/ubunu-root, /dev/mapper/ubunu-swap. The /boot partition on the flash drive (this is sdb1).

In the installer window, at step 8, you need to click the "Advanced" button and make sure that the bootloader will be installed on the flash drive:

In Ubuntu 12.04, both partitions and bootloader are in one window:

After this, in the window of step 8, you need to click the “Install” button and wait until the installation is completed. Once the installation is complete, the installer will prompt you to restart your computer. You can't reboot! You need to stay in Live Ubuntu. The fact is that in the installed HDD Ubuntu does not have the lvm2 package, which means that booting the system from the hard drive will not be possible.

Installing LVM on a hard drive

To install lvm2 on a freshly installed Ubuntu on your hard drive, you need to run the following commands:

sudo mount /dev/mapper/ubuntu-root /mnt
sudo mount /dev/sdb1 /mnt/boot
sudo mount -o bind /dev /mnt/dev
sudo mount -t proc proc /mnt/proc
sudo mount -t sysfs sys /mnt/sys

sudo cp /etc/resolv.conf /mnt/etc/resolv.conf
sudo chroot /mnt /bin/bash
echo "crypted UUID=$(ls -la /dev/disk/by-uuid | grep $(basename /dev/sda1) | cut -d " " -f 9) none luks" >> /etc/crypttab
apt-get update
apt-get install cryptsetup lvm2
exit

Note 1. In Ubuntu 12.04 instead cut -d " " -f 9 need to write cut -d " " -f 11! In addition, I recommend that after the echo ... /etc/crypttab command, run the cat /etc/crypttab command to check that the line was written correctly:

Note 2. After the penultimate command there will be error messages, you can ignore them.

Now you can restart your computer and use the installed encrypted Ubuntu. Of course, in the BIOS you need to specify booting from the flash drive where the /boot partition is installed!

In Ubuntu installed in this way, you can even use hibernate mode, without fear that the contents of the memory flushed to disk will become accessible to an attacker.

Note 1

It is important to understand that even with such total encryption, vulnerabilities remain.

First, you need to keep the key phrase secret. If you write it down on a sticky note and stick it on the monitor, it’s not good. If an attacker receives the passphrase, he will be able to open your encrypted disk using any Live Linux distribution.
Secondly, you need to protect the bootable USB flash drive at the physical level. Do not leave her unattended. Turn off the computer - remove the flash drive and place it in a safe place.
Thirdly, you should not leave it unattended. included computer. When the computer is turned on, both the encrypted disk and the bootable USB flash drive are available.

You also need to understand that encryption is protection for the time when your computer is turned off and you are not around. But when you work on a computer, there is still the possibility of malware getting onto your computer from the Internet. Such programs can "steal" your information while you are using your computer and the Internet.

Therefore, it is important to take general protective measures. Don't wander around anywhere on the Internet. Do not install unverified programs. Use a firewall. And for more serious security requirements, you need to use tcb And SELinux.

Note 2

Make a copy bootable flash drive, the easiest way is with the command dd. Write this image to another flash drive or laser disk. A copy to another flash drive is more convenient because, if necessary, you can use it immediately. But in any case, this copy, no matter what it is on, will need to be stored in a secure place. And after updating the kernel or bootloader, you will need to update a copy of the flash drive.

Ivan Sukhov, 2012

When writing this article, information was used from a publication in

TrueCrypt is no longer supported, but dm-crypt and LUKS are great open source options for encrypting and using 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 just the responsibility of websites, there is a lot that we as end users can do for our own security. For example, just some examples - use strong passwords, encrypt hard disks, which are located on our computers, and use secure connections. In particular, hard drive 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 TrueCrypt, a well-known open-source disk encryption tool, stopped development. As many of you know, it was one of the very reliable tools designed for disk encryption. 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 that also have a lot of configuration options. We'll look at two of them - dm-crypt and LUKS - as alternatives 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, indicating what encryption is used, the encryption mode, hashing algorithm, and other cryptographic data.

Resources

Step 01: Considering Dm-crypt

The app name dm-crypt is short for device mapper-crypt. 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 functions, such as dm-cache (creates hybrid volumes), dm-verity (designed to check block integrity, 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 files are accessible immediately after the disk is mounted - there is no visible delay to the end user. To encrypt using dm-crypt you can simply specify one of the symmetric ciphers, the encryption mode, the key (of any valid size), the IV generation mode, and then create a new block device in /dev. Now, any writing to this device will be encrypted, and any reading will be decrypted. You can mount a file system on this device as usual, or you can use the dm-crypt device to create other designs, such as a RAID or LVM volume. The dm-crypt lookup table is defined as follows:

Here, start-sector is typically 0, size is the device size in sectors, and target name is the name you want to give to the encrypted device. The target-mapping table consists of the following sections:

[<#opt_params> ]

Step 02: Considering LUKS

As we have already seen 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 will not create metadata on disk, and this can be a serious problem if you want to ensure compatibility between different Linux distributions. In addition, the dm-crypt application does not support the use of multiple keys, whereas in real situations it is very important to use multiple keys.

It is for these reasons that the LUKS (Linux Unified Key Setup) technique was born. LUKS is the Linux encryption standard hard drives and standardization allows for compatibility between different distributions. The use of multiple keys and passphrases is 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, users can easily switch to any other distribution. The dm-crypt project currently recommends using LUKS as the preferred way to configure 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 used in dm-crypt is already present in all Linux distributions; we only need an interface to them. We will use the cryptsetup utility, with which you can create volumes using dm-crypt, the LUKS standard, as well as the good old TrueCrypt application. 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 receives information about latest versions all available packages. The second command will download and install the cryptsetup package on your computer. If you are using a 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 must create a target file that will store the LUKS container. Although there are many ways to create such a file, there are a number of conditions that must be met when creating it:

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

The dd command can help us create a file that satisfies the above conditions, although it will be relatively slow. Just use it with a special device file /dev/random specified as input and a target file specified as output. An example command looks like this:

$ dd if=/dev/random of=/home/nitish/basefile bs=1M count=128

As a result, a file called basefile with a size of 128 MB will be created in the /home/nitish directory. However, please note that this command may take quite a long time to complete; in the system our expert used, this took an hour.

Step 05: Create dm-crypt LUKS

Once you have created the target file, you need to create a LUKS partition in that file. This section serves as the main layer on 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

Once 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:

$file basefile

Please note that the phrase you enter here will be used to decrypt the data. It is very important to remember this and keep it in a safe place, because if you forget it, you will almost certainly lose all the data in the encrypted partition.

Step 06: Create and mount the 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 the 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:

Once you successfully enter the passphrase you 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 because it is the newest file system for Linux systems.

$ mkfs.ext4 -j /dev/mapper/volume1

Once the device is successfully formatted, the next step is to mount it. First you should create a mount point, preferably at /mnt (based on common sense).

$mkdir/mnt/files

Now let's 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 takes up some space in the device.

Thanks to this step, you can now use the LUKS device with ext4 file system. Just use this device to store files - 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 drive

We followed several steps to achieve this result, and if you are not very clear on how it all works, you will most likely get confused about what you need to do only once (required for installation), and what needs to be done regularly when using encryption. Let's consider the following scenario: You have successfully completed all the steps above and then shut down your computer. The next day, when you start your computer, you are unable to find the mounted device - where did it go? To figure all this out, you need to keep in mind that after the system starts, you need to mount the LUKS container, and before stopping the computer, unmount it.

To access your LUKS file, do the following every time you turn on your computer, and then safely close the file before turning 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 as follows:

$ umount /mnt/files

After successful unmounting, close the LUKS file:

$cryptsetup luksClose volume1

Step 09: Backup

Most losses of data stored in a LUKS container are due to corruption of the LUKS header or key slots. In addition to the fact that even due to accidental rewriting of a header into memory, LUKS headers can be damaged, in real conditions a complete failure of the hard drive is also possible. The best way protecting yourself from such problems is backup. Let's see what backup options are available.

To create backup copy 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, then specify the luksHeaderRestore parameter in the command:

$ sudo cryptsetup luksHeaderRestore /home/nitish/basefile --header-backup-file /home/nitish/backupfile

To check the LUKS header file and ensure that the file you are dealing with corresponds to an actual LUKS device, you can use the isLuks parameter.

$ sudo cryptsetup -v isLuks /home/nitish/basefile

We've already seen how to backup LUKS header files, but a LUKS header backup won't actually protect against a complete disk failure, so you'll need to back up the entire partition using the following cat command:

$ cat /home/nitish/basefile > basefile.img

Step 10: Various settings

There are several other settings that may be useful when using dm-crypt LUKS encryption. Let's 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 ( Translator's note: key slot - key space):

$ 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 a total of eight key slots, 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, otherwise your data will be lost forever.

I don't understand Canonical. It seems that on August 23 we passed the freeze of new FeatureFreeze features, and on August 30 we passed the freeze appearance UserInterfaceFreeze. What do we actually see? In the installer Ubiquity now has the ability to encrypt the entire system and in Unity Greeter adds network indicator and network login feature.

Encrypting entire Ubuntu during installation.

As you can see, Canonical has implemented disk encryption in the Ubiquity graphical installer to strengthen the security of Ubuntu 12.10 Quantal Quetzal. Such functionality was previously only available in Alternate CD, but as you know, Canonical plans to abandon alternative discs.

If you select "Encrypt new installation Ubuntu for security" (“Encrypt the new Ubuntu installation for security”), then in the next step you will have to enter the encryption keys.

Additionally, for added security, there is an option to overwrite empty disk space, but this will make the installation process a little longer.

Remember that any files outside of the Ubuntu installation are not encrypted! In the future, new disks and new partitions will not be encrypted by default and you must remember this.

And do not confuse the encryption of all Ubuntu partitions with the encryption of the Home folder!

Unity Greeter network and welcome screen.

There have been some minor cosmetic changes with Unity Greeter. The welcome window has become wider and closer to the center. The rounded corners made the overall look visually softer. The font displaying the username has been slightly reduced. Maintaining the overall style, the password entry field was highlighted in a subtle orange color. The list of sessions available to you has changed, instead of a “simple list” there are now “buttons”.

Along with the above changes, the developers have added a network indicator.

Therefore, when logging in, you can easily disable network connections or view the current network status to ensure that network login is possible.

Judging by the official changelogs, we are preparing to introduce network login capabilities to Unity Greeter in the near future.

The magic lamp is now enabled by default.

A window recovery effect known as Genie or Magic Lamp was available in Compiz previously, but in Ubuntu 12.10 it will be enabled by default.

Author: Nitish Tiwari
Date of publication: 04 February 2015
Translation: N. Romodanov
Translation date: March 2015

TrueCrypt is no longer supported, but dm-crypt and LUKS are great open source options for encrypting and using 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 just the responsibility of websites, there is a lot that we as end users can do for our own security. For example, just some examples are using strong passwords, encrypting hard drives that are located on our computers, and using secure connections. In particular, encrypting your hard drive 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.

This is basic information about a device using LUKS, indicating what encryption is used, the encryption mode, hashing algorithm, and other cryptographic data.