How does RAM Encryption work

[RAMEncryption]

I can't find anything how the Veracrypt memory encryption works. I'm really curious since you normally need a key in RAM, but a key in RAM could be read and then the encryption key could be decrypted...

[Mounir IDRASSI]

I have promised before to explain more RAM encryption implementation and the rational behind it but I never was able to do it. This is an oppportunity to finally explain this part which should also be present on the documentation (I will try to find time for that too!).

RAM encryption mechanism serves two purposes: add a protection against cold boot attacks and add an obfuscation layer to make it much more difficult to recover encryption master keys from memory dumps , either live dumps or offline dumps (without it, locating and extracting master keys from memory dumps is relatively easy).

First, here is a quick summary on how RAM encryption is implemented. All memory variables used are allocated in Kernel space as non paged memory so it is never accessible to user space applications.

1. VeraCrypt driver allocates at Windows startup a large memory region with a size of 1MiB. If allocation fails, then it allocated a 8 KiB non-paged memory region.
2. This memory region is filled with random bytes generation by a CSPRNG based on ChaCha20.
3. We generated two random 64-bit integers (HashSeedMask and CipherIVMask) that will be used in the RAM encryption algorithm.
4. The RAM encryption algorithm will use a key that is the result of derivation from the above memory region combined with unique values derived from the memory that will be encrypted (we combine HashSeedMask and CipherIVMask with several virtual addresses values). This ensures that a unique key is used for each memory region that will be encrypted.
5. This key derivation takes place everytime we need to use the master key of a volume. So we need a very fast way to derive key otherwise it will be too slow to be usable. For that we use the non-cryptographic hash t1ha2.
6. The master key of a volume are decrypted for each request so we need a very fast algorithm for decrypting master key. For that we use ChaCha12.
7. After a volume is mounted, either system or non-system, we immediatly encrypt its master keys using the algorithm described below before doing any operation with the volume.
8. For each I/O request received for a volume, we copy the encrypted master keys to a local variable, then we decrypt this location variable using algorithm described below, then we use this variable to perform encryption/decryption needed for the I/O request and finally we securely wipe this local variable.
9. When the volume is dismounted, we securely wipe the encrypted master keys from memory.
10. When Windows is shutdown or rebooted, we securely wipe the large memory region that was allocated at startup.

The rational behind cold boot attacks mitigation is as follows: by using a large memory page as input for key derivation, we ensure that attacker won't be able to recover master key since at least some portions of this large memory area will be corrupted and can't be recovered and so the attacker will not be able to derive the correct keys used for encrypting master keys. There have been papers published in then past about such technique (cf https://www.blackhat.com/presentations/bh-usa-08/McGregor/BH_US_08_McGregor_Cold_Boot_Attacks.pdf, https://www.grc.com/sn/files/RAM_Hijacks.pdf).
Without this RAM encryption mechanism, a cold boot attack is able to recover easily a portion of the master key and then the attacker can use brute force to recover the rest of the key.

The non-cryptographic hash algorithm t1ha2 was chosen to derive keys from the large memory region for performance reasons after bench-marking several algorithms including standard ones like SipHash. Since we are deriving key from 1MB memory region every time a data need to be encrypted or decrypted, we need a hash function that has a speed in the GiB/s otherwise on-the-fly encryption/decryption will become unusable. t1h2 provide good quality hashing and more importantly it erspects the strict avalanche criteria which is important for our use case.

ChaCh12 was choosen for RAM encryption instead of ChaCha20 for performance reason also. ChaCha12 offers an encryption strength that is enough for our case while giving us a very fast encryption/decryption speed.

As a side note, I want to mention that an additional security layer was introduced in 1.24 which combines well with RAM encryption: it is the mechanism of detection of insertion of new device in the system when System Encryption is used. Once activated, if a device is inserted, master keys are immediately erased from memory which leads to a Windows BSOD.
This mechanism protects against certain attacks that use special devices to extract memory from running systems. But in order to be really effective, this mechanism should be combined with RAM encryption since it is not guaranteed that RAM chips will quickly erasethe requested memory cells and so attackers may resort to cold boot attacks in such case.

The algorithm to compute a unique ID for the RAM buffer that will be encrypted is implemented in the function VcGetEncryptionID from src/Common/Crypto.c.
The algorithm used for encrypting RAM is implemented in the function VcProtectMemory from src/Common/Crypto.c.

Algorithm VcGetEncryptionID:
- Input: pCryptoInfo, a CRYPTO_INFO variable to encrypt/decrypt
- Output: A 64-bit integer identifying the pCryptoInfo variable
- Steps:
- compute the sum of the virtual memory addresses of the fields ks and ks2 of pCryptoInfo variable: encID = ((uint64) pCryptoInfo->ks) + ((uint64) pCryptoInfo->ks2)
- return the result

Algorithm VcProtectMemory:
- Input:
- encID, a 64-bit integer which is the unique ID associated with memory that will be encrypted
- pbData, a pointer to the memory to be encrypted
- pbKeyDerivationArea, the large memory area allocated by the drive upon startup
- HashSeedMask and CipherIVMask, two 64-bit random integer generated at startup
- Output:
- None, the memory pointed by pbData is encrypted in place
- Steps:
- compute a 64-bit seed value that will be used as input for t1h2 hashing: hashSeed = (((uint64) pbKeyDerivationArea) + encID) ^ HashSeedMask
- compute 128-bit hash of pbKeyDerivationArea: hash128 = t1h2 (pbKeyDerivationArea,hashSeed)
- compute the 256-bit key for ChaCha12: chachaKey = hash128 || hash128
- compute the 64-bit IV for ChaCha12: chachaIV = encID ^ CipherIVMask
- encrypt memory pointed by pbData using ChaCha12: ChaCha256Encrypt (chachaKey, chachaIV, pbData)
- securely erase all temporary values computed during this process

Since ChaCha12 is a stream cipher, encryption and decryption are the same so VcProtectMemory is used for both encryption and decrypt.

I'm open to comment on the design and its security and I'm interested in feedback on the real cost of implementing extraction of keys encrypted this way from memory dumps.

As an enhancement to the current RAM encrytion mechanism, it is possible to include in the algorithm the use of random values stored in the CPU debug registes. This will make the mechanism completely immune to attacks since there CPU registers are inaccessible from memory dumps, they can be accessed only by kernel drivers and there content is cleared when CPU shutdown or reset.

The only drawback of this solution is that it will interfer with the usage of kernel debugging but normally those who perform kernel debugging will not activate RAM encryption. Anyway, if anyone wants to implement this idea, it will be more than welcomed.

[Dave]

Thanks for explaining this.
Should VeraCrypt warn users to diasable hibernation and fast startup in Windows 8/10, as either can lead to problems with RAM encryption?

[Enigma2Illusion]

MS Fast Start effects more than RAM encryption.

https://sourceforge.net/p/veracrypt/tickets/180/

[RAMEncryption]

Hi Mounir IDRASSI
thanks for explaining RAM encryption that detailed.

The master key of a volume are decrypted for each request so we need a very fast algorithm for decrypting master key. For that we use ChaCha12.

For each I/O request received for a volume, we copy the encrypted master keys to a local variable, then we decrypt this location variable using algorithm described below, then we use this variable to perform encryption/decryption needed for the I/O request and finally we securely wipe this local variable.

But where exactly do you store the decryped masterkeys? I think it will find its way back to the RAM.
From this masterkey there is then the AES round keys derived. Do you also derive them or are these round keys not stored anymore because of AES-NI? As far as I know even if there is decay/error in this round keys somewhere you can correct this error with the rest of the round keys, because there is some redundancy in it.

Back to the storage location: Probably the unencrypted masterkey and the AES round keys are stored in RAM. So it is a matter of propability if the key is currently in RAM or not. If you have a heavy load on the encrypted disk, the probability is very high. If you use full disk encryption Windows will constantly access disk and thus the key will be a lot of times present in RAM. Since windows does a lot of work in background if the computer is idle for some time an attacker just has to wait. If he then sees high activity on the HDD LED he cuts power / cold boots at that moment and with a high probability the unencrypted key is somewhere in RAM.

Even if you manage to store the unencrypted values only in the registers you can't prevent them to get stored into RAM by a context switch. Tresor https://faui1-files.cs.fau.de/filepool/projects/tresor/tresor.pdf

To suppress context switching,we run AES atomically. The atomic section is enteredjust before an input block is encrypted and left againright afterwards. Therefore, we can use arbitrary CPUregisters to encrypt a block; we just have to reset thembefore leaving the atomic section. This guarantees thatno sensitive data leaks into RAM by context switches.

They use a kernel patch, probably to achive this atomic operation. However on Windows there is no atomic operation possible https://stackoverflow.com/questions/288364/win32-atomic-execution-of-code-block You can just reduce changes to get preempted by executing your thread in real time priority. But still it can be preempted by other threads running at real time priority and probably hardware interrupts, too. And since sheduler has to check if another thread wants to run, which generates a hardware interrupt, registers are also written to RAM. Perhaps not on a multicore CPU because the ISR can be executed on another CPU core, but there is no guarantee.

So as far as I understand it is currently just a mater of probability if masterkey is present in RAM and an attacker can increase his opportunities to provoke disk access with just waiting for windows doing its idle tasks. Or just pulling ethernet plug and reconnecting it should cause some disk activity or accessing a service which wasn't use for some time so it is not cached in RAM. You can try with RDP for example or try accessing network shares.

Hope you can tell me that I'm wrong and missed something so that RAM encryption is more secure than a matter of probability.

[Mounir IDRASSI]

Thank very much @ramencryption for your feedback.

Your assessment is aboslutely correct and it is impossible to avoid that the master keys are in RAM in clear format at a certain moment for a short period of time since we need to do computations using CPU after all. The keys are decrypted on stack memory at each call, in a location that changes depending on various parameters, whereas without RAM encryption the ley are always present at the same location.

RAM encryption reduces the probablity of master keys being in RAM and so it is more secure than without it but at the same time it is not a 100% guarantee that keys can never be found in RAM.

In practive, we only store derived round keys not the master key. For AES-NI, the round keys are loaded each time we need to perform an operation, so round keys must be present in RAM when doing encryption/decryption.

Because of Windows caching and buffering for I/O operations, cryptographic operations don't happen continuously but rather in concentrate events separated by idle times. That being said, in high load scenarios, the time separation between these culculation events is shorter and indeed there will be high probabily of finding round keys in clear in RAM.

Thank you for sharing the TRESOR paper. I have actually stambled upon it and other similar papers when doing research for RAM encryption and the idea of using CPU debug registers that I mentionned in my first post comes from my reading of these various papers. Currently, we don't use this approach but if in the future we want to add a register-only mechanism for holding master keys, then context switching can be problematic on Windows even if we already run our threads in real-time priority range.

The subject of protecting keys in RAM is complex and what I have implemented in VeraCrypt is a small step towards a foolproof solution that maybe doesn't exist. Neverthless, at the current state of things, it is better to have an imperfect protection than no protection at all.

As I wrote in my first post, I'm open to contributions for enhancement of RAM encryption mechanism. The current implementation provides simple functions that can be overriden for any new protection mechanism without carring much about the complexity of VeraCrypt driver itself.

[Dave]

So hibernation and fast startup (hybrid sleep?) do not work with RAM encryption. In the meantime, can VeraCrypt offer to disable hibernation and fast startup before RAM encryption can be used (with user's consent)? As pointed out earlier, fast startup causes other problems.

When RAM encryption is used, could hibernation (along with fast startup and hybrid sleep) work if the keys were written to the encrypted drive when the user hibernates Windows (similar to what happens when RAM encryption is not used and the user hibernates Windows)?

[Mounir IDRASSI]

@daver4: I will implement disabling hibernate and fast startup when enabling RAM Encryption.

Concerning your question about hibernation, we can support it only if the large memory region that we use to derive keys for RAM Encryption is stored encrypted with keys different from those usually used for VeraCrypt encryption of the current drive (otherwise we will have a chicken-egg problem). This means this large memory region must be stored in a different drive using an encryption format that can be unlocked with the same password as the one used for Pre-Boot authentication. And since that we need to do this at a very early stage, we will not have the ability to access filesystem content so the encrypted value must store raw in specific sector location of the other disk. This is very cumbersome and while it is technically doable, I don't think it is practical for normal deployment. Thus, I don't see any possibility for supporting hibernate while RAM Encryption is enabled.

[Dave]

@Mounir
Thank you for explaining this so well.
When the user selects RAM encryption, please inform the user that hibernation and fast startup will be disabled (and the reasons why).

[RAMEncryption]

What about a differenct approach: Upon hibernating you set this 1 MiB Memory region to 0. Then you derive the encryption key from this "Zero region" and encrypt the neccessary keys with this. Then upon boot you intialize that region again with Zeros and as soon as poosible you correctly initialize it and encrypt the Round-Keys accordingly.

Perhaps another suggestion. Upon hibernation you "disable" RAM encryption. Keys would be stored in plaintext, but since we use full disk encryption they're in fact encrypted. So from that point everything is the same as with the current full disk encryption. Then after boot you reenable RAM encryption.

[Enigma2Illusion]

Both options you propose would create more security vulnerabilities for VeraCrypt.

For example, using zeros to derive the new keys lead to security issues for Wi-Fi devices known as Kr00k.

The second proposal assumes everyone is using system encryption. Users may create VeraCrypt non-system volumes and/or file containers without encrypting their system drive.

[RAMEncryption]

Hi Enigma2Illusion,

Thanks for your thoughts. With Kr00k key was zeroed out and still encrypted with it. That lead to the security issue. Here we only encrypt the encryption key so all data to disk will be securely encrypted.

Concerning system encryption. If you don't use system drive encryption you have to unmount all volumes otherwise volume key would be stored in cleartext in the hibernation file. So there would be no security changes for those users.

[Enigma2Illusion]

I am not understanding your proposal which seems to open a vulnerability using the "Zero region" which has been set to zeros.

What about a differenct approach: Upon hibernating you set this 1 MiB Memory region to 0. Then you derive the encryption key from this "Zero region" and encrypt the neccessary keys with this. Then upon boot you intialize that region again with Zeros and as soon as poosible you correctly initialize it and encrypt the Round-Keys accordingly.

.

Concerning system encryption. If you don't use system drive encryption you have to unmount all volumes otherwise volume key would be stored in cleartext in the hibernation file. So there would be no security changes for those users.

For users not using system encryption, this exposes their encryption keys in the hibernation file to which MS Fast Startup is a hybrid hibernation. The issue reported by a user in the thread below meant he was unable to shutdown his system due to MS Fast Startup was enabled when using RAM encryption. The user had to "hard shutdown" aka crash his system to turn it off since the system appeared to just come back to the Windows login prompt.

https://sourceforge.net/p/veracrypt/discussion/technical/thread/d71190471c/

Someone would need to test this scenario to see if the encryption keys were written to a hibernation file since the system would simply start at the Window login prompt which would confirm your statement that "there would be no security changes for those users". :)

[Andy Solomon]

It's been nearly a year now, is it now implemented?

[Enigma2Illusion]

Yes starting with 1.24 version. See the release notes to read the details for RAM encryption.

https://www.veracrypt.fr/en/Release%20Notes.html

[Andy Solomon]

My bad, I phrased the question incorrectly.
Mounir said that he will "implement disabling hibernate and fast startup when enabling RAM Encryption". That was my question, if that is implemented already and not the RAM Encryption itself.

[Enigma2Illusion]

For future reference, open the Release Notes and use the search feature of a webpage in your browser when you are looking if something has been fixed or a certain feature has been added to VeraCrypt.

For example, I searched on "RAM encryption" on the release notes.

Mounir said that he will "implement disabling hibernate and fast startup when enabling RAM Encryption". That was my question, if that is implemented already and not the RAM Encryption itself.

Yes. Starting with 1.24 update 7.

[RAMEncryption]

The subject of protecting keys in RAM is complex and what I have implemented in VeraCrypt is a small step towards a foolproof solution that maybe doesn't exist. Neverthless, at the current state of things, it is better to have an imperfect protection than no protection at all.

As I wrote in my first post, I'm open to contributions for enhancement of RAM encryption mechanism. The current implementation provides simple functions that can be overriden for any new protection mechanism without carring much about the complexity of VeraCrypt driver itself.

Have you thought about using SGX? https://en.wikipedia.org/wiki/Software_Guard_Extensions
There memory is encrypted.

[Mounir IDRASSI]

@ramencryption: both suggestions for hibernate suppose that we can implement a kind of "stop the world" mechanism in VeraCrypt driver in order to be able to modify the state of RAM Encryption at runtime.
I don't think this is possible without risking to cause OS deadlocks, especially in the case of hibernate. There are many threads running in parallel handling various tasks and blocking the hibernate request while we wait for all threads to switch to new RAM Encryption state seems to be a little risky. I have no idea how Windows will behave in such case but at this stage I'm almost sure that we will end up causing a freeze of Windows.

If we are able to implement a "stop the world" mechanism, then I would go with the proposal of disabling RAM Encryption before hibernate and enabling it again when resuming. This would be the cleanest and the most robust approach.

Concerning SGX, actually I have been in contact last year with a university student who was working on SGX implementation for VeraCrypt( not related to RAM Encryption). The task was too complex and he could not achieve any useful results in the given time but I'm still hopeful that we can have at least a PoC.
I didn't think about using SGX for RAM Encryption but now that you mention it maybe this can be a good solution to protect the keys used for RAM Encryption. Unfortunately, SGX programming is complex and what we can do with it is limited so more study is needed to evaluate feasability.

Maybe an easier alternative would be to use Windows VBS enclaves : https://www.microsoft.com/security/blog/2018/06/05/virtualization-based-security-vbs-memory-enclaves-data-protection-through-isolation/. These are secure memory enclaves that seem to enable more flexibility for programming tasks while providing guarantees about the security of data stored in the enclave. I will dig more to learn about VBS enclaves and how we can use them in VeraCrypt.

[cryptolover]

SGX isn't secure at all, it has lots of disclosed vulnerabilities, just take a look at Intel's own advisories page, it lists at least half a dozen SGX issues. And those are only the ones which have been found and acknowledged.
It's also Intel only and poorly documented.
Furthermore, hardware based security is inherently flawed because it's hard to patch holes once they are found. It requires firmware updates, which stop being released quite quickly and carry a danger of bricking the device.
I don't know about VBS, but I certainly don't trust MS to do anything properly. If I trusted them, I'd just use bitlocker.

Something that might be useful against cold boot attacks is an option to wipe all RAM contents on shutdown like Tails does.

[Vincent LORENTZ]

Good morning,

I use this threat to ask a very critical question: on my PC, I had memory encryption activated, because I had activated it before the version generating the warning about Fast Start and Hibernate was released. So I have apparently just deadly crashed my PC...

Here is what I have done:

Starting point: PC with an SSD with Windows 10 Pro 64bit, and a separate RAID array with SSD containing all the data files and documents, encrypted with VeryCrypt (the Windows SSD is not encrypted with VeraCrypt). The RAM encryption option was enabled (check box was checked).

Several months ago, I have activated Hibernate but disabled Fast Start, and I have made some checks because my PC always had issues with Standby, therefore I wanted to use Hibernate, and I activated it. Here, nothing bad happened.

While I have installed another PC for my father, I noticed the warning concerning Hibernate and Fast Start issued when activating RAM encryption. I remembered that on my PC, Hibernate was activated, so I decided yesterday to get safe and disable RAM encryption on my PC too...

VeraCrypt has asked me to restart the operating system (Hibernate was still not disabled at this stage, but I have never used it in the last 4 weeks). I restarted Windows 10... and after the restart, I logged in normally. However, some second after the login, the system rebooted automatically again?! And it was from now on doing this every time I log in!!!

After a while, I started in Safe Mode with Networking Support: here I uninstalled VeraCrypt to hope that Windows will no more try to start it, so that it will not crash... This was certainly the second very bad idea, because now my PC is even not starting any more in Safe Mode!!!??

I did not loose (yet!) my data files, but I have tons of critical software installed on the Windows SSD and reinstalling Windows and reconfiguring all the additional programs would take months!!!

The message during the Windows 10 Safe Mode Startup is a blue screen with "CRITICAL PROCESS DIED"

I am totally desperate. If anyone have an idea how I could get out of this mess, I would be very grateful. Thank you very much.

Best regards

[Peter]

@Mounir: Gemini and ChatGPt firmly and stiffly claim that there is a secondary key that decrypts the master key. This secondary key is stored in the encrypted RAM in plain font. With a CBA, the RAM is copied and the secondary key is located with the elcomsoft app and thus the master key can be decrypted. Is that the danger you mentioned? We are now in 2025. Or has something changed?

@Mounir: Gemini und ChatGPt behaupten fest und steif, dass es einen sekundär-Schlüssel gibt, welcher den Hauptschlüssel entschlüsselt. Dieser sekundärschlüssel ist im verschlüsselten RAM in Klar Schrift gespeichert. Bei einem CBA wird der RAM kopiert und der sekundärschlüssel mit der elcomsoft app lokalisiert und somit kann der Hauptschlüssel entschlüsselt werden. Ist das die von dir erwähnte Gefahr? Wir haben jetzt 2025. Oder hat sich da etwas geändert?