RAM key encryption and Windows hibernation/fast startup
Open source disk encryption with strong security for the Paranoid
Brought to you by:
idrassi
Menu
▾
▴
When RAM key encryption is enabled, fast startup and hibernation in Windows will not work.
Solution?
Is it possible to decrypt the key from RAM and save the decrypted key onto the encrypted disk or container file (encrypted)? It would solve the problem and allow hibernation and fast startup to work normally in Windows. When resuming from hibernation (or fast startup), the key is encrypted in RAM again. Therefore, the key remains encrypted in both RAM and on the disk, so an attacker cannot retrieve it.
I don't see any easy solution for this chicken-egg problem.
The only place on the disk where we are allowed to write is the volume header and it is not enough to store the keys. We could define a disk space to store data but the filesystem must be made aware of it so it doesn't get overwritten. And since VeraCrypt works below filesystem, we will not be able to access this space at boot...
We could just choose some free sectors and hope that OS will not touch it during hibernate process...but this is not a professional way of doing things.
Even if we suppose that we are able to find a place for store the keys encrypted using the system partition master key, I'm not sure we will be able to restore their value "on time" for the encryption/decryption threads when they are resumed by the system. Theoretically, we need to decrypt the key from disk and encrypt it again using the session key derived from the 1MiB seed and relative address value. And this must be synchronized correctly while Windows is performing various Read/Write operation during boot.
Maybe I'm missing something but at this stage I'm convinced that there is no secure way to support hibernate when RAM encryption is used. I should really write a technical documentation about RAM encryption mechanism so others can look at it and the source code and possibly propose some ideas like yours.
Someone could find a solution, if they are determined, so we can have the best of both worlds (hibernation and encrypted keys in RAM). :-)
TRESOR processes the keys in the CPU to avoid unencrypted keys leaking into RAM, but it’s still vulnerable in other ways.
https://en.wikipedia.org/wiki/TRESOR
When enabling the RAM key/password encryption in the VeraCrypt GUI, it would be wise to warn the user that hibernation and fast startup (Windows 8/10) will not work. Either VeraCrypt could disable both (if possible) or instruct the user on how to disable them.
In my opinion it is not worth spending any time and energy into finding a solution for this "problem".
Reason: Nowadays there is no need for a hibernation mode, because with SSDs there is no real disadvantage for cold boot time including a session restore compared to a hibernation boot.
Therefore many Linux versions do not support the hibernation mode any more to avoid the many other problems related to it.
VeraCrypt may be less secure on SSD or flash drives: https://www.veracrypt.fr/en/Trim%20Operation.html
SSD drives are becoming increasingly common, so hibernate and fast startup is becoming less important. But many computers still have hard disks; fast startup (or hibernation) is beneficial for hard drives with Windows installed for performance reasons. Hard disk drives will not be disappearing any time soon.
Another possibility?
When hibernation is invoked or fast startup enabled, maybe VeraCrypt could decrypt the keys from RAM and write these keys to a file (whose contents will have to be encrypted). Upon resuming from hibernation or fast startup, access the keys from this file and encrypt them in RAM.
It should not matter if the said file is defragmented. But if the file ever gets corrupted or moved, VeraCrypt could revert to unencrypted RAM and warn the user that RAM encryption has been disabled (because the file is moved, missing or corrupted). If the user enables RAM encryption again, a new file can be created automatically.
I agree that boot up time benefits from hibernation and fast startup while using a standard hard disk. The need for fast bootup only occurs when using mobile devices; but they have SSDs or should have them as well for shock resistance.
On the other hand the "long" bootup time in relation to the time of use makes it really a very tiny benefit.
I am convinced that nobody would miss hibernation and fast boot and would be glad to have gained the much more useful increase of speed after replacing the old HD by a SSD.
So I consider the development of a solution to deal with hibernation a waste of time.
VeraCrypt will be less secure on SSD or flash drives, due to wear levelling and TRIM (see the VeraCrypt documentation).
If users need plausible deniability, a hard disk drive should be used (provided the SMART data shows no reallocated or bad sectors). There are many millions of computers today with hard drives and SSD’s will not be replacing hard drives overnight.
If there is no possible fix, RAM encryption of keys will not work with fast startup and hibernation. Said this before: if the user enables RAM encryption, VeraCrypt should warn the user that hibernation (and fast startup) will not work and disable both or prompt the user to do so, because the average user would not know about this.
I believe that it’s worth exploring all possible solutions before giving up entirely.