Making VeraCrypt encrypted containers impenetrable

[Man]

Hello!
VeraCrypt is the most popular fork of the famous TrueCrypt encryption tool. Why is it often preferred? VeraCrypt has open source code and its own format of virtual and encrypted disks that is more secure than TrueCrypt. VeraCrypt sources have been independently audited, and the vulnerabilities found have since been closed, making Vera even more reliable.

DISCLAIMER: This article is provided for informational purposes only and does not constitute a call to action. All information is intended to protect readers from illegal activities.

How the police hack VeraCrypt containers​

This article is not about how to break cryptocontainers. However, if you do not know how experts will act when trying to access encrypted data, it will be difficult to understand the meaning of the described actions.

The actions of the expert in the laboratory depend on what exactly and how exactly was seized during the search.

Standard methods​

The most typical case is the removal of external storage devices entirely; computers are turned off and also removed entirely, but the expert does not receive the entire computer in the lab, but only the disks removed from it.

This scenario is the very case that developers of all cryptocontainers without exception have been preparing to counter for so long. Brute-force attacks on cryptocontainers are ineffective, and on some of their varieties (in particular, boot partitions encrypted in TPM or TPM + key mode) they are absolutely ineffective.

In a typical case, the expert will first try to analyze the hibernation and swap files. If the user has neglected the security settings of the cryptocontainer (by the way, when using BitLocker, these settings are far from obvious), then the encryption keys are easily extracted from these files, and the encrypted volumes are decrypted without lengthy attacks. Of course, in some cases this attack will not work. It will be useless if at least one of the conditions described below is met.

1. The boot disk is encrypted. In this case, both the swap file and the hibernation file will also be encrypted. For example, if BitLocker is used to encrypt the boot partition (this makes sense even if the rest of the data is encrypted in VeraCrypt containers), then Microsoft describes the security model in detail in the FAQ and BitLocker Security FAQ (section What are the implications of using the sleep or hibernate power management options?). By the way, there are exceptions to this rule - for example, if the swap file is located on a separate device from the boot device (a fairly common case for users who "save" the boot SSD resource in this way).

2. The computer was shut down in a normal manner (using the Shutdown command) or was removed in a hybrid sleep or hibernation state; in this case, the crypto container is configured to automatically unmount encrypted volumes and destroy encryption keys in RAM when the computer goes into sleep, hibernation, or is turned off.

Is it a bit difficult to understand? I'll simplify: if the encrypted volume was mounted at the time of seizure, and the police simply pulled the plug out of the socket, then the encryption key will most likely remain in the hibernation file (whether it can be pulled out from there depends on point 1). But if the computer was turned off with the Shutdown command, then the presence or absence of the key will depend on the settings of the cryptocontainer. We'll talk about how to properly configure VeraCrypt later.

3. Finally, the obvious: analyzing swap and hibernation files is completely useless if the encrypted volume was not mounted at the time the computer was removed.

If the encryption keys cannot be extracted, the expert will search for them in the cloud or corporate network (for volumes encrypted with standard BitLocker or FileVault 2 tools). Only after that will a brute-force attack be used - password guessing.

Password guessing is also not easy. Firstly, the times when a "frontal attack" meant a simple brute force are long gone. The attack speed will be such that a full guessing of the entire password space becomes useless if the length of the password to the cryptocontainer exceeds 7-8 characters. Accordingly, dictionaries are used for attacks, primarily dictionaries made up of the user's own passwords (they can be extracted from the user's computer, mobile devices or directly from the Google Account cloud). Methods for analyzing passwords and creating template rules, on the basis of which "similar" passwords will be generated, have long been developed.

To carry out the attack, the police will use one of the few software packages that can launch an attack on multiple (in theory, up to several thousand, in reality, hundreds) computers, each equipped with several graphics accelerators. Sounds unlikely? However, during police training sessions around the world, I have seen rooms with computers used for distributed attacks. I can tell you the following about them. The creators of science fiction films are obviously not allowed into these rooms, so we have to watch the pathetic fruits of a pathetic fantasy on cinema screens. Just to show the scale, I will share a fact that amazed me: on the desktops of police experts in one British backwater there are computers with a GeForce 2080 and 40 processor cores.

To begin with, the search area will be limited to the set of characters that appear in user passwords.

Next, they try an attack with mutations (a word is taken from the dictionary and its variants are checked, compiled according to fairly simple rules used by the vast majority of ordinary users). By the way, mutations are most often where attack attempts end in cases where the police have no leads - they were unable to obtain a single user password.

If this does not work, masks will be used (attempts to manually construct passwords “similar” to those found on the user).

In particularly complex cases, it will come down to hybrid attacks (using combinations of one or two dictionaries in combination with scripted rules, masks and/or prefixes).

Unconventional methods​

The police begin to act unconventionally in rare cases when the suspect is presumed to have encrypted "digital evidence". In this case, trained experts go with the operatives to supervise the seizure and try to examine the switched-on, working computers right on the spot. The expert will try to do the following.

1. access to the computer desktop. Everything is clear and known here.
2. Make a dump of the computer's RAM. This is possible if you managed to gain access to the desktop (by the way, in the case of multi-user computers, you can use any administrative account for this), but it is not necessary: for example, an attack via DMA is deservedly popular, which has gained a second wind after the release of computers with Thunderbolt technology support via the USB-C port.
3. Finally, in particularly difficult cases, a cryogenic attack can be used. Its rarity and exoticism is evidenced by the fact that in all my work I have not met a single expert who would perform such an analysis in practice.

What does the choice of encryption algorithm affect?​

Back in the days of TrueCrypt, users were offered a choice of different encryption algorithms, including several options with sequential encryption of data first with one algorithm and then with another. In VeraCrypt, the choice has expanded significantly. Now, five algorithms are offered (AES, Serpent, Twofish, Camellia, and "Kuznechik") and ten options for their sequential use.

For patriots who want to use the domestically developed encryption algorithm "Kuznechik", I recommend that you familiarize yourself with the information about the oddities in the permutation tables, which clearly indicate the existence of a deliberately left "back door".

The average VeraCrypt user does not understand how the algorithms differ, is not interested in the details, but believes that if you choose a chain of two, or even better, three algorithms, then you will definitely be protected from both secret service backdoors and from vulnerabilities in the algorithms themselves.

The truth is that it will be enough to use the most well-known and simplest algorithm from a computational point of view. The same AES, which is used by everyone - from children downloading a new game to their phone, to financial tycoons and the most special intelligence services. In decades of widespread use and mass research, this algorithm has not been cracked, no secret back doors have been found.

What does the choice of encryption algorithm actually affect? Another sad truth: only and exclusively the speed of access to encrypted data.

AES encryption uses commands built into modern processors (from the cheapest ARMv8 cores to even very old Intel and AMD processors) for hardware acceleration of encryption. Other algorithms can also use these commands. But AES is used by everyone, and other algorithms are not used by everyone, so their optimization leaves much to be desired. The most optimized Camellia encryption algorithm is one and a half times slower than AES in encryption speed, Twofish is three times slower than AES, Serpent is four times slower, and Kuznechik is four and a half times slower. Combined options work even slower, without providing any additional security.

So, choosing an encryption algorithm other than AES cannot improve the security of encrypted data, but it can easily worsen it. What can improve it?

Selecting a hash function and the number of iterations​

In order to encrypt (and decrypt, too) any data, a cryptocontainer does not use a password. For encryption by any algorithm (from AES to "Kuznechik"), a binary key of a fixed length is used, the so-called Data Encryption Key or Media Encryption Key (MEK). How exactly does your password (surely very long and secure) turn into a fixed-length MEK? Frankly speaking, in no way. The Media Encryption Key for a container created once is immutable; it is stored in an encrypted (or rather, "wrapped") form directly within the container, and in an "unwrapped" form is used to access the data.

The MEK data encryption key is necessarily encrypted (forgive the tautology) with the Key Encryption Key (KEK). Without KEK, it is impossible to decrypt the MEK, and without MEK, it is impossible to decrypt the data. Why do we need such a complex scheme? At least so that you can change the password for the cryptocontainer without the obligatory decryption and re-encryption of all the contents. However, the role of the MEK/KEK key pair is not limited to this scenario. Thus, it will be enough to erase several dozen bytes in the container header (overwriting the area in which the MEK is stored), and no one will ever be able to decrypt the container again, even if the password is known exactly. The ability to instantly and irreversibly destroy data is an important part of the overall security strategy.

So, we've sorted out the MEK/KEK key pair. How does one get a KEK key from a password? VeraCrypt performs a cyclic sequence of one-way (this is important) mathematical transformations - hash functions, and the number of cycles is quite large: by default, the transformation is performed 500,000 times. Thus, with the "default" settings, VeraCrypt will spend from one to five or six seconds to calculate a single KEK key based on the entered password.

Here comes the important point. Remember, a little above I analyzed the speed of encryption algorithms and recommended using AES as the most common and fastest option? Well, with the choice of a hash function, everything is exactly the opposite: you need the most non-standard and the slowest algorithm.

VeraCrypt has a choice of four hash functions: the default SHA-512 (it's quite slow and quite secure, but it's the default, which is a minus for us), the even slower and also well-studied Whirlpool, the old SHA-256, which is still secure but I don't see the point in using it, and the "dark horse" Stribog, which is the slowest in the benchmark.

However, the words from Wikipedia reliably discourage the use of the Stribog hash function: “Developed by the Center for Information Protection and Special Communications of the FSB of Russia with the participation of InfoTeKS OJSC based on the national standard of the Russian Federation GOST R 34.11-2012 and put into effect on June 1, 2019 by order of Rosstandart No. 1060-st dated December 4, 2018,” as well as some trivial errors and oddities in the permutation tables found by independent researchers.

How to properly configure the password to KEK encryption key conversion? Here are three main points.

1. Don't use the default option. All software for cracking cryptocontainers without exception is configured to attack with the "default" settings. An expert will have a choice of settings (default, select a specific combination of parameters, or try all combinations). The "default" attack will be the fastest, the "try all combinations" option will be catastrophically slow, and trying to select the correct combination of encryption parameters manually is the same as manually selecting a password.
2. Choose the slowest hash function (but not "Stribog"). Yes, with a slow hash function, and also different from the "default choice", your crypto container will be mounted not one, but five to six seconds - but the resistance to attack will also increase by the same five to six times (and taking into account the "non-default choice" - even more).
3. Change the number of iterations. More on that below.

So, we've sorted out the default settings and decided on the hash function. However, there is one more important parameter hidden behind the inconspicuous Use PIM checkbox. What kind of PIM is this and why is it needed?

PIM (Personal Iterations Multiplier) directly affects the number of iterations that will be used to transform your password into the KEK encryption key. According to the documentation, VeraCrypt calculates the number of iterations (the number of transformations) using the formula 15,000 + (PIM*1000). For the SHA-512 and Whirlpool hash functions, the default PIM value is 485, which gives us exactly 500,000 iterations.

What is this parameter for? The thing is that computing power, including that of those who will hack your cryptocontainer, is constantly growing. Protection that was effective twenty years ago no longer seems so impenetrable today. However, in the case of VeraCrypt, you can easily and elegantly increase the security strength as much as you like by simply increasing the number of iterations. Yes, increasing the number of iterations (via a custom PIM value) will slightly reduce the ease of use (when mounting a cryptocontainer, you will have to enter the PIM number in addition to the password), and the mounting speed will slow down a little. Believe me, however, that any, even the slightest change in PIM means a huge headache for anyone who decides to pick a password.

How much will changing PIM affect the speed of mounting a crypto container? Here is the time with default PIM settings.

But I changed the PIM to 500 (from the default 485).

And here I used a PIM of 1000.

The numbers are not at all exorbitant: it is not difficult to wait extra seconds when mounting an encrypted volume, but anyone who tries to pick up the password to it will have a lot of problems. The general algorithm of the hackers' work will look like this.

1. First, they will try all possible attacks with standard settings. This is time, often significant.
2. If it is clear that the PIM value is non-standard, and the PIM number is known exactly, the attack will be carried out immediately with the correct setting. However, increasing the PIM from 485 to 1000 will increase the time required for the attack by approximately two times. Not a great increase in security, but better than nothing.
3. But if the PIM value is unknown to the attacker, then the attack will have to be carried out for the entire range of PIM values. That is, if you set the PIM value to 1000, then the attacker will have to check EVERY password variant with PIM values = 1, 2, 3, …, 1000 (or 485, 486, 487, …, 1000, if the attacker is convinced that you did not decrease the PIM value, but only increased it). In other words, the complexity of the attack increases as a multiple of the value (your PIM - 485), if the attacker uses only variants that exceed the default value, or by (your PIM) times, if the attacker decides to try the entire range of PIM values.

A logical question: wouldn't increasing the password length by two or three characters from the extended character set give a similar (and even better) result? From a purely computational point of view, it would. The reality is that most attacks are carried out with default settings; programs capable of using attacks with a non-standard PIM value can be counted on the fingers of one hand, and programs capable of automating attacks with a custom set of PIM values are even fewer.

Let's look at a screenshot of the latest build of Elcomsoft Distributed Password Recovery with VeraCrypt support (by the way, it hasn't even been officially released yet).

Here we see an attack in a standard configuration: the encryption algorithm is AES, the hash function is SHA-512. No surprises. The attack speed is 170 passwords per second (this is with the load of all processor cores and using the computing resources of the video card; without a video card, we would see a speed of about 0.5 passwords per second).

But if you change the hash function, then the attack shown in the first screenshot will not be able to find the password. Accordingly, the second attack will be used - this time across the entire spectrum of encryption algorithms and hash functions.

What do we see in the second screenshot? First, the speed of the search has dropped sharply to one password per second - this is using a GPU accelerator.

What don't we see in the second screenshot? We don't see the ability to attack the number of PIM iterations. The number of PIM iterations in most password cracking programs can be specified manually. Thus, a non-standard number of iterations will make the attack ineffective: even if your password is 123, it will not be possible to find it without specifying the exact number of iterations.

Of course, if there is a problem, there is a solution. The latest beta of the well-known hashcat tool declares two interesting parameters: --veracrypt-pim-start and --veracrypt-pim-stop (commit with change). And what will happen to the speed of the search? If the exact encryption parameters are unknown (a combination of the encryption algorithm and the hash function), then the speed of the search is already quite low: only one password per second on a computer with a hardware GPU accelerator. Now divide this figure by the number of possible PIM variants, and you will get an extremely slow search. In reality, the search will be even slower: if with low PIM values the password check takes a fraction of a second, then a large number of iterations will slow down the search several times compared to the standard value.

Encryption Key Protection​

So, we chose AES encryption, Whirlpool hash function, and the number of iterations was modestly set to 1111 (to be non-standard and not to forget accidentally). This will completely protect the container from a password attack, but, as we remember from the beginning of the article, the police may not arrange such an attack at all if they can simply pull the encryption key from your computer.

Taking a ready-made encryption key and using it to mount (or decrypt the entire) encrypted partition is the favorite and fastest method used by the police. The essence of it is as follows.

As you know, a cryptocontainer does not use a password to encrypt (and decrypt) data. To encrypt with any algorithm (from AES to "Kuznechik"), a binary key of a fixed length is used, the so-called Data Encryption Key or Media Encryption Key (MEK). You already know how complexly your password (surely very long and secure) turns into a key of a fixed length. That's not the point now.

It is logical that the data encryption key (MEK) is stored in the computer's RAM. This is necessary so that the crypto container program can access the encrypted data in principle. Please note: the encryption key is stored in RAM completely independently of the encryption algorithm you selected in the container settings. AES, Twofish, Serpent, "Kuznechik" or any combination of algorithms - regardless of your choice, the encryption keys will be stored in RAM, and the complexity and speed of their extraction are almost the same.

Thus, the complexity of this attack depends little on the choice of encryption algorithm or on the method of converting your password into a binary key. The maximum that can be achieved with non-standard settings is an increase in the time it takes to search for a key in the RAM image, say, from ten to fifteen minutes to one and a half to two hours (the numbers are arbitrary: much depends on the amount of RAM in the computer from which the dump was made, as well as on the speed of the drive and the central processor where this dump is analyzed).

Is it possible to protect yourself from such attacks? Full protection against extracting encryption keys from the computer's RAM is quite complicated, and on a regular desktop it may be completely impossible (it is quite difficult to resist a cryogenic attack in general, but the probability of its use is also vanishingly small). At the same time, you can enable the recently introduced option of encrypting encryption keys in the computer's RAM in the VeraCrypt settings.

Please note: this setting is available starting with VeraCrypt 1.24 (at the time of writing, the current build is 1.24 Update 4). By default, the option is disabled; if enabled, the driver's RAM usage will increase by about 10%, performance will drop by 5-15% (source), and the hibernation feature will be disabled.

But this is only part of the protection. The data itself, which is stored in the encrypted container, can also get into the swap file or hibernation file, and the built-in VeraCrypt hibernation disable function may not work. Ideally, it should also be disabled at the Windows level. The Hybrid sleep option and, actually, Hibernation.

Also note the Fast Startup mode in the first screenshot. In this mode (by default, by the way), when you turn off your computer, Windows saves the kernel state to a file on the system disk. This file is a kind of truncated (without user space) analogue of the hibernation file. Its presence allows you to speed up the subsequent boot process, but it also leads to the possibility of leaking the VeraCrypt volume encryption key. Disabling Fast Startup mode will help protect against this vulnerability.

If you don't want to sacrifice the hibernation mode, you should consider encrypting the system disk using the same BitLocker. In this case, both the swap file and the hibernation file will be reliably protected.

Cloud and access recovery keys​

For VeraCrypt, this point is not critical, but BitLocker by default offers the user to save the recovery key for access to the encrypted disk in the OneDrive cloud. If it can be extracted from there (and the police usually can, it is enough to make a request to Microsoft), then decrypting the data becomes trivial. The attack will also work if you save such a key on a USB drive, which can be accessed by a police expert or an intruder. In other words, recovery keys are a double-edged sword, and from a pure security point of view, it is better not to have them than to have them.

Conclusion​

I hope I have changed your ideas about the security of cryptocontainers in general and VeraCrypt in particular. Armed with new knowledge, you will be able to create encrypted containers that are several orders of magnitude more resistant to password attacks. In addition, using recently introduced little-known security settings will allow you to protect yourself from favorite attacks on RAM, swap files, and hibernation. At the same time, the developers of VeraCrypt do not guarantee the security of any data that gets into the computer's RAM, so we are not talking about 100% protection, but rather about a significant complication of the corresponding attacks with an equally significant decrease in their effectiveness and the likelihood of successfully opening an encrypted volume.