This project has moved and is read-only. For the latest updates, please go here.

Move the encryption key from memory to CPU

Topics: Feature Requests
Nov 11, 2016 at 12:04 AM
I've seen this:

«TRESOR is a secure implementation of AES which is resistant against cold boot attacks. The basic idea behind this implementation is to store the secret key inside CPU registers rather than in RAM. All computations take place only on registers, no AES state is ever going to RAM. In particular, the x86 debug registers are misused as secure key storage. Running TRESOR on a 64-bit CPU that supports AES-NI, there is only little performance penalty compared to a generic implementation of AES. The supported key sizes are 128, 192 and 256 bits (full AES).

Running TRESOR on a plain old 32-bit CPU, supporting at least SSE2, is possible as well. But you get a performance penalty of about factor six compared to generic AES and the only supported key length is 128 bits. Thus, we recommend to use TRESOR in combination with one of Intel's new Core-i processors supporting AES-NI (e.g., Core-i5 or Core-i7).»

So is it possible to make VeraCrypt also use this feature (at least optional if the computer supports it) in order to stop the grab of the private key from the memory? One less problem.
Nov 28, 2016 at 12:45 PM
Doesn't context switching save the contents of CPU registers into memory?
I think using CPU cache would be more appropriate.
Nov 29, 2016 at 10:44 PM
Could you explain how do you plan cold boot attack on personal encryption tool?
Dec 11, 2016 at 7:09 AM
From the wikipedia:

«In cryptography, a cold boot attack (or to a lesser extent, a platform reset attack) is a type of side channel attack in which an attacker with physical access to a computer is able to retrieve encryption keys from a running operating system after using a cold reboot to restart the machine. The attack relies on the data remanence property of DRAM and SRAM to retrieve memory contents that remain readable in the seconds to minutes after power has been removed.

To execute the attack, a running computer is cold-booted. Cold-booting refers to when power is cycled “off” and then “on” without letting the operating system shut down cleanly, or, if available, pressing the “reset” button. A removable disk is then immediately used to boot a lightweight operating system, which is then used to dump the contents of pre-boot physical memory to a file. Alternatively, the memory modules are removed from the original system and quickly placed in a compatible machine under the attacker's control, which is then booted to access the memory. Further analysis can then be performed against the information that was dumped from memory to find various sensitive data, such as the keys contained in it (automated tools are now available to perform this task for attacks against some popular encryption systems).

The attack has been demonstrated to be effective against full disk encryption schemes of various vendors and operating systems, even where a Trusted Platform Module (TPM) secure cryptoprocessor is used. This is because the problem is fundamentally a hardware (insecure memory) and not a software issue. While the focus of current research is on disk encryption, any sensitive data held in memory is vulnerable to the attack.

With certain memory modules, the time window for an attack can be extended to hours by cooling them with a refrigerant such as an inverted can of compressed air. Furthermore, as the bits disappear in memory over time, they can be reconstructed, as they fade away in a predictable manner. In the case of disk encryption applications that can be configured to allow the operating system to boot without a pre-boot PIN being entered or a hardware key being present (e.g. BitLocker in a simple configuration that uses a TPM without a two-factor authentication PIN or USB key), the time frame for the attack is not limiting at all.

This is not the only attack that allows encryption keys to be read from memory—for example, a DMA attack allows physical memory to be accessed via a 1394 DMA channel. Microsoft recommends changes to the default Windows configuration to prevent this if it is a concern.

The ability to execute the cold boot attack successfully varies considerably across different systems, types of memory, memory manufacturers and motherboard properties, and is more difficult to carry out than software-based methods or a DMA attack.»

That is what this "TRESOR Runs Encryption Securely Outside RAM" is for... the decryption keys stop being available in the memory at all... stopping a few more attacks then just the cold boot attack but also other attacks that are aiming at the insecure memory.
Dec 11, 2016 at 11:08 AM
About tresor. Interesting work. All keys in registers.

Probably VeraCrypt Linux version can be based on tresor if it is available in kernel.

For Windows we can not support it. (no sources of Windows ;)

I wrote about personal use because to perform cold boot attack it is necessary to have keys in memory(authorized) and physical access to computer.

Note: Keys in registers are not the only possibility. Better way is to create separate hardware device for this. (Probably TPM is too slow)
Dec 11, 2016 at 8:15 PM
I think a very easy, though not really neat solution for the evil maid attack would be possible if the victim uses the same password for veracrypt and for locking his computer (ie the windows password, screensaver password, etc.).