ram encryption blue screen

[Andrei Matanache]

Hello, 1st of all i have a question about ram encryption. Is this suppose to render useless cold boot attacks or forensic tools extracting the keys from ram ? It would be nice if someone could actually test this to confirm.

Ok back to the blue screen, it doesn't seem to be working for me. I thought it was working fine after enabling it but actually it needed a reboot to get it enabled.
I have tried on 2 different computers with different encryption algorithms (one being serpent(aes) ,both with whirpool, on windows 10 pro with last updates, everytime it gives blue screen saying SYSTEM THREAD EXPECTION NOT HANDLED , what failed :veracrypt.sys
I dont have any dumps since they are disabled for memory leaking reasons .
Both were containers , i don't have any drive/system encryption so i can't talk about that.
Pretty sad about this, i was really exciated to see this added.

[SelectLine]

hmm...

Windows 8 (64bit) OK. no bsod

[Andrei Matanache]

was it system encryption or container ? Can you try making a small container with whirpool and serpent(aes) and also use a keyfile so we can see if windows 10 is the one causing it or something else?

[SelectLine]

you have turned on or off ??

[SelectLine]

MBR or EFI system?

[Andrei Matanache]

i cant acess that option since i dont have system encryption, it is uefi bios but is again irrelevant since i am using containers and not system encryption

[SelectLine]

ok, BSOD also for Windows 8.

reported for Mounir IDRASSI

Thank you Andrei Gheorghe

Edit:
" i dont have system encryption"

my mistake . excuse me

[Andrei Matanache]

what did you changed to trigger the blue screen?it is because i am using containers or because of whirpool ?

[SelectLine]

probably the problem is related to "keyfiles"

[Mounir IDRASSI]

Hi Andrei,

I'm planning to publish a detailed technical write-up about RAM encryption implementation and objectives but I still don't have time to do so.

Concerning RAM encryption, it has two objectives: the first is indeed to thwart cold boot attack and the second is to make it more difficult to extract keys from the RAM of running systems.

Both objectives are achived by encrypting the keys using a random key that is unique for each volume. This random key is derived each time we need to access sectors on the volume (either read or write). The key derivation is based on the hash using t1ha (with a unique seed) of large memory segment (1MB) that is allocated on non-paged memory by the driver and which is filled with random data. The key encryption uses ChaCha12 which is secure enough and very fast at the same time.

For cold boot attacks, the security of this scheme relies on the fact that the probability that some cells in this large RAM region will not be recoverable by an attacker is very high and so he will not be able to compute the correct hash. Moreover, the use of unique seed values for each volumes during the hash calculation makes it more difficult for attackers since these seed values change everytime and are not fixed.

For live RAM extraction attacks, this scheme also add more difficult compared to the previous versions of VeraCrypt where keys were stored in clear text and in easily identified regions.
Moreover, VeraCrypt 1.24-Beta also introduced another option when system encryption is used that will make VeraCrypt erase keys from memory when a new device is plugged to the system. This protects against RAM extraction using specialy crafted hardware devices and if combined with RAM encryption it will render such RAM extraction attacks impossible.

Concerning the blue screen issues, I don't have it on my physical test systems (Windows 7 and Windows 10 with latest updates) and also on virtualized test systems (also Windows 7 and Windows 10). On these system, I have used system encrytion and file containers and they all use SHA-512 and AES so maybe there is something specific about other algorithms.

I will do tests using the configuration you described (non system encryption and file container with Whirlpool and Serpent(AES)) and I will let you know.

Meanwhile, is it possible to know the CPU model your machines are using? This can be important since algorithm implementation depends on CPU features and such BSOD can be triggered if the correct CPU feature is not handled correctly.

[Andrei Matanache]

hey,thanks for getting back with detailed answer.
since my motherboard doesn't have FireWire and thunderbolt I assume I am safe from live ram extraction and even if someone would have,disabling this ports also renders useless this attacks if you have windows lock screen that can't be bypassed without a reboot as far as I know.am I right?

also when saying about plugging in a device I assume you mean to wipe the keys if the firewire or thunderbolt port is being accessed

my cpu is 9900k i9 ,don't forget to use a keyfile too

[Mounir IDRASSI]

Device insertion protection applies to all ports and not only FireWire/Thunderbolt.
Actually, there are many attacks that use USB ports and the Windows lock screeen can do nothing to protect against such attack.
VeraCrypt option against device insertion applies only when system encryption is used and after it is enabled, if any device is inserted to the machine using any port (USB, PCI, FireWire; Thunderbolt..), VeraCrypt driver will erase all encryption keys from memory in a quick way that will render the system unusable after this since Windows can not access the encrypted disk. This is a special option that should be used only on special situation where the machine is left unattended in an untrusted environement.

If system encryption is not used, then this option can not be enabled but it is possible to implement an application that will run in the background and call VeraCrypt driver to erase keys if a device is inserted. Maybe I will implement such application in the future for users who don't use system encryption.

Concerning the BSOD, I was not able to reproduce it in any of my machines. I created a small file container using Whirlpooil and Serpent(AES). I also used a keyfile and a password and I'm able to mount it without any issue while the RAM encryption option is enabled. I did tests using empty password, short password and long password (128 characaters) but no BSOD.

Can you please share the exacte details of the file container that causes the issue (password length, key file size, container size...)? Or maybe you can post a test file container alongside its key file and password so that I can use the same files as you?

One point is that all my machines use System encryption and right now I don't have a machine without system encryption. Maybe that's the difference but I will wait to see if you can post a test file container to try to reproduce with it.

[Andrei Matanache]

well actually i have set up my windows to disable usb ports when windows is locked and automatically re-enable them when you logged in so since i have no firewire and thunderbold ports i assume that (hopefully) i am safe from such attacks .What do you think about this?
It would be nice to add this option for containers too to wipe keys but only if lock screen is ON to avoid false positivies .
Also i am looking further to fix nvme ssd speeds in a future release as they became very popular.
i am on not on those pcs with the problem now but ill try a quick test on the one i am to see if i can reproduce the problem, otherwise ill come back tomorrow reproducing the problem on my main pcs.
Edit:
I was able to reproduc this on this pc too,i couldnt even complete the creation since the wizzard auto mounts and i got bsod.
Here is what settings i have used.
Created cointainer with hidden volume so i used for outer volume AES, whirpool, NO key file, small password , FAT format(i think that's the default one), as for the hidden one i used whirpool aes(serpent) with ntfs format and keyfile.
This should reproduce the problem in win 10, if not, i will give upload the container and send it to you.
Outer volume seems to be mounting fine , ill probably try more combinations later to isolate the problem even further

[Mounir IDRASSI]

Indeed, your approach is good provided that you never forget or be distracted from locking Windows. But there is still HDMI/DVI although I'm not aware of any real world exploitation of them (who knows!).
Adding an option to activate this protection only during lock screen can reduce false positives but it will open an attack window even if it is small.
NVME SSD speed issuse is another subject and a very long one...

OK, i'm waiting for your feedback and I will also try for find a machine without system encryption to do tests.

[Andrei Matanache]

it gets locked automatically if i'm away for few mins and even reboots on 2 fail passwords attemps and i took this even further haha but i am already giving too much details
you should add the option to wipe only when lockscreen is ON to avoid the hassle to disable that options everytime you want to plug in something and being in a hurry will surely make tons of false positives , best way to please everyone is to make it wipe while lock screen is ON optionally and don't forget us using containers and not system encryption(the main reason i dont use system encryption is because of the nvme problem)
anyway back to bsod i was able to reduce this for you to spend less time on finding the bug and more time for fixing
i removed the keyfile and used default HKDA so definitly is not from there
so this comes to this. It either happns on all hidden volumes, it either happens on all hidden volumes with ntfs format(while outer is FAT).
You might also want to test this in the same way but with system encryption too not only with containers.
Also could be worth mentioning that i did this last tests changing the settings of the container with the problem and didin't start from scratch with the new settings(no keyfile and default HKDA) .
Waiting for news to know the problem was found and it will be fixed on next update.Thanks

[Enigma2Illusion]

@Mounir,

I am experiencing the same problem being reported in this thread on 1.24 Beta 3 with the RAM encryption enabled on my Windows 10 Pro 64-bit Version 1803 OS Build 17134.619 system. No system encryption.

Running several tests with file containers and external HDD, the issue occurs when a hidden volume is involved.

Tests Performed

Success Scenarios

• Create new file container using NTFS, Whirlpool, Serpent short password with no keyfiles on unencrypted system drive.
• Mount new file container that does not contain hidden volume on unencrypted system drive.
• Mount new file container outer volume without protecting hidden volume on unencrypted system drive.
• Mount new file container hidden volume on unencrypted system drive.

.
BSOD Scenarios

• Create new file container with hidden volume using NTFS, Whirlpool, Serpent short password with no keyfiles on unencrypted system drive.
• Mount new file container hidden volume on unencrypted system drive.
• Mount file container without a hidden volume on a VeraCrypt encrypted external drive's outer volume with hidden volume protected.
• Mount external HDD hidden volume.

.
I hope this helps you in your analysis to recreate the various scenarios causing the BSOD.

I have restored my system to the C drive image using Macrium Reflect back to 1.24 Beta 2.

[Andrei Matanache]

i;m either drunk or your explanation makes no sense.
you have "Mount new file container hidden volume on unencrypted system drive." on both success and bsod scenarios.
I was never able to mount a hidden volume succesfully no matter the settings. Only outer volume works

[Enigma2Illusion]

@Andrei ,

I should clarify, I did receive BSOD when I attempted to create the file container with hidden volume. The BSOD occurred during create hidden volume phase.

Attempting to mount the new file container's hidden volume that BSOD during creation resulted in the same BSOD error instead of various other non-BSOD errors like volume not formatted, etc.

EDIT: I see your confusion regarding the success mount. "Mount file container without a hidden volume on a VeraCrypt encrypted external drive's outer volume with hidden volume protected."

EDIT 2: I was mounting a file container that did not contain a hidden volume that is located on an external HDD that was mounted to the outer volume with protection enabled for the hidden volume on the external HDD encrypted volume.

@Mounir,

Another detail I just remembered is that the file container that I mounted today that failed with BSOD, successfully mounted yesterday. To my knowledge, no Windows updates occurred other than virus definitions since I have my system group policy set to notify for Windows updates.

[Andrei Matanache]

"file container that I mounted today that failed with BSOD, successfully mounted yesterday."
this probably has to do with the fact you didin't reboot after enabling/disabling the ram encryption. I thought too that it worked fine on 1st try but the ram encryption turned on only after you reboot your pc.

[Enigma2Illusion]

I installed and rebooted 1.24 Beta 3 on March 3rd when it was released. I shutdown my system daily. So something else happen between yesterday and today that caused my system to BSOD when I attempted to mount the file container today.

I did notice a strange issue of trying to enter my password last night for mounting the external HDDs. I started typing my password and somehow my system lost focus on the password field and my attempts to click on the password field were unsuccessful in getting focus back to the password field.

I clicked Cancel or the X in the corner to abort and re-attempted again without issue. I not sure if I somehow fat fingered a command that prevented me for getting back into the password field. That is the first time that happen to me.

This morning, again the problem with losing focus on the password field occurred again except I was able to click on the password field to regain focus on the password field and continue normally mounting the external drives. When I attempt to mount the file container on the encrypted external drives is when I got the BSOD error that you reported.

That is why I used my Macrium Reflect to restore my C drive image prior to the 1.24 Beta 3 upgrade since I am not sure what happened to my system.

[Andrei Matanache]

you have to reboot AFTER enabling ram encryption from options.The simple fact that you installed the last version and rebooted doesn't mean anything since ram encryption is disabled by default.Losing focus on password field i dont think is related to vera, maybe some other program goes on top of it even for a split second.Anyway i hope the developer has enough info now to fix the issue, i am really excited about this option

[Enigma2Illusion]

I do not believe that the option to enable encryption of the VeraCrypt keys in RAM requires a reboot or the developer would have the UI prompt you to reboot in order to enable this feature.

Only Mounir can provide the answer if a reboot is required to enable the RAM encryption of the VeraCrypt keys.

I had the RAM option enabled after the reboot as part of the upgrade on March 3rd and then I shutdown my PC later that night. Hence, the file container I mounted successfully yesterday should have failed yesterday with the BSOD instead of today.

@Mounir,

I case it matters, my PC has a 3rd generation Intel Core i7-3720QM CPU. aka Ivy Bridge.
16 GB memory of RAM.

[Mounir IDRASSI]

Thank you all for your help in testing and analyzing this issue.
I was able to find the cause of this BSOD and I implemented a fix for it. I released 1.24-Beta4 which solves this problem.

I have been working on RAM encryption for several months now and the implementation went through many non published iterations. Although I spent a great amount of time in testings and benchmarking, I overlooked this part of the code. I'm grateful to the community for helping to test such new feature and especially Andrei to taking the time for fill the report and do the extra tests.

@Enigma2Illusion: The RAM encryption option requires reboot to be activated but I didn't display the warning for the users about this. In previous implementation of RAM encryption (that I didn't publish) reboot was not required but after many tests I arrived to the conclusion that it was more robust to apply it only from reboot. Unfortunately, I forgot to update the UI to reflect this change in the implementation. Now in 1.24-Beta4 I display the proper warning when the user enables RAM encryption.

[Andrei Matanache]

just tested and it works fine now.Thanks for the fast update. Hopefully someone can test some cold boot attacks and live ram extraction to see if he can find the keys now.
Hopefully in next release you can add the option for containers to wipe keys when a device is added and lock screen is on too,i don't see why containers shouldn't have the same security strength . Good day !

[Enigma2Illusion]

@Mounir,

Sorry to report that I am still having problems with the RAM encryption option using beta 4.

Issues:

• When I go to mount using my Favorites using Secure Desktop, sometimes the password field is unavailable on the first volume to be mounted. I have to cancel. The second Favorite to be mounted allows access to the password field.
• When I mount using Favorites the outer volume while protecting hidden volume, the volume mounts. However, if I try to access the mounted volumes, I get the Windows error that the volume needs to be formatted before use.
  • When I disable RAM encryption, reboot, remount using Favorites, I am able to access the mounted drives without error and access the files and directories.

.
These are external HDDs using partition encryption.