@Null: Concerning the System Favorite issue, you have certainly enabled the option "Allow only administrators to view and dismount system favorite volumes in VeraCrypt" in System Favorites configuration dialog as shown in the screenshot below. You can uncheck this option to see mounted system favorites without running VeraCrypt as Admin.
Concerning your RAM encryption question, if the cjeckbox of RAM encryption is Driver Configuration dialog is ticked, then it is enabled. This checkbox is ticked only if the corresponding registry key is present on the Windows Registry (only Admin can modify this key) and if RAM encryption is enabled in the registry and VeraCrypt is not able to use it for some reason (this will never happen in normal case), then VeraCrypt driver will provoke a Windows BSOD to stop the machine. This is a radical approach to ensure that RAM encryption is used correctly and securely.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With the change to RAM encryption to prevent Windows from hibernating only occur when any of the following three conditions are met?
Using system encryption.
Or the user currently has cached passwords.
Or the user currently has a non-system VeraCrypt volume mounted.
.
In other words, if you are not using system encryption, no passwords are currently cached and no volumes are currerntly mounted, will the machine be able to hibernate?
Last edit: Enigma2Illusion 2019-10-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Enigma2Illusion: If the user doesn't use system encryption, then Hibernate will be allowed even of RAM encryptioion is enabled. I will add this clarification to the Releaase Notes.
That being said, I would advice against Hibernate while RAM encryption is enabled if there are mounted volumes. Of course, it is more secure than without RAM encryption but a sophisticated attacker could still analyze the Hibernate file on the disk and do computations to retrieve the RAM encryption keys and used them to decrypt mounted volumes master keys.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Would having the option in preferences to dismount all when entering power saving mode avoid the above issue?
Yes, with this option enabled, volumes will be dismounted before the Hibernate take place and so the encrypted master keys will not be written to disk. Hibernate file will not be useful to the attacker in this case.
The only attack possible is if the attacker is able to dump the RAM of a running machine which has mounted volumes, so that he can do brute force analyzis of the RAM encryption layout and try to decrypt master keys (not an easy task). There are hardware devices that can be connected using USB or firewire to a machine to perform RAM dump on live machines and that's why VeraCrypt implements a protection mechanism to erase encryption keys when a device is connected to the machine but this is only available when system encryption is used.
Maybe in the future I can add this feature to the case where systeme encryption is not used. For now, there is an entry point in VeraCrypt driver (VC_IOCTL_EMERGENCY_CLEAR_ALL_KEYS, cf https://sourceforge.net/p/veracrypt/code/ci/master/tree/src/Driver/Ntdriver.c#l2668) that allows erasing volumes encryption keys and which requires administrative privileges. So others can implement software solutions based on this IOCTL to protect machines from rogue devices insertion.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Perhaps the veracrypt website should be updated also with the new changelog. I also want to point out there is a newer libzip version available 1.5.2 to update to.
Last edit: Mikael 2019-10-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This isn't true. GPT isn't just an enterprise thing anymore. Any computer that ships with Windows 10 installed is running what is called UEFI instead of BIOS. UEFI can boot legacy BIOS mode, but to sell the machine with Windows 10 they are required to boot UEFI mode. UEFI mode cannot boot from MBR. It requires GPT. So, all newer machines that come with Windows 10 pre-installed (also ones that came with Windows 8/8.1) have the primary drive in GPT format.
VeraCrypt can encrypt GPT format drives, and it isn't smart to tell people to stop using the newer UEFI over the old BIOS. Without UEFI, secure boot is also disabled. Secure boot is designed to make sure there are not any malware in the boot process. Formatting in MBR/BIOS boot means secure boot has to be disabled and malware now can inject itself in the boot process. Compromising the entire machine.
Also, with the way you laid out how to convert from GPT to MBR you forgot one critial thing. You will have to go into the UEFI and disable secure boot, and than turn on legacy BIOS boot. Following what you said will leave them with an unbootable system.
I am running a Razer Blade 15 Adv 2018 in UEFI mode with GPT formatted drive. The reason you cannot encrypt the entire drive is that the boot process needs to have a partition unencrypted to contain the boot loader. Windows BitLocker does this same thing. Format the system drive the only way you are allowed and if you have any other partitions on there, then format them seperate and load them as system favorites.
Last edit: 1210 2019-10-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Whole drive encription (I am assuming this is every part of the drive, except the MBR, encrypted.) isn't needed. With UEFI you just encrypt each partition separately, except the EFI and any recovery partitions. Nothing is inherently insecure with partition by partition encryption. It will be the way to encrypt UEFI systems going forward, unless something changes. It is the way my two machines running with VeraCrypt are set up. The system does not store any data outside of the partitions you are encrypting. Just the GPT format information.
If I am wrong, then Mounir IDRASSI can correct me.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
DO NOT reinstall Windows in BIOS/MBR setup. You need to keep the drive in GPT. It is best this way. Secure boot requires UEFI booting, which requires the drive to be in GPT. Secure boot verifies boot elements to make sure no virus/malware has injected code to completely compromise your system.
You can encrypt each partition seperately. Your drive is in GPT format, and this is necessary for Windows 10 to boot with secure boot, there is a partition, called the EFI partition, which is around 128-512 MB in size. Most of the time you cannot see this through Windows explorer. Disk Management will show this partition. This stores the bootloaders for any operating system. Windows has its own bootloader there. VeraCrypt will put one there, too. These need to be unencrypted or there is no way you can sart the system in UEFI with secure boot on. VeraCrypt's bootloader will deal with the encryption (and asks you for your password) until the Windows VeraCrypt driver takes over.
Last edit: 1210 2019-10-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would imagine that Jean's problem will be very common. Perhaps Veracrypt should inform the user in this situation WHY it can't encrypt the system drive? This would stop the bug reports and forum posts. Also, there could be a brief explanation of the steps to take to remedy this perhaps? It's just a suggestion, and I'm just an end-user, not a developer - although I have donated several times.
I'm glad Mounir has returned and development has picked up the pace. I'm enjoying watching the progress. Thanks everyone
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is very common and you are right. I am sure there are many people out there wondering whether or not their system truly has FDE. VC should explain why only the OS partition can be encrypted. The VC textbox should also include the ramifications and security comparisons vs whole drive encryption and steps the users can take to configure their system to enable whole drive encryption, if desired. The program has a fairly easy to understand interface execpt for this one issue. Fortunatly it's an easy fix.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Regarding the comments of having VeraCrypt provide a message about being unable to encrypt the entire system drive when UEFI is involved, can create confusion to the end user that may lead to the impression that something is wrong with the setup of their system.
Microsoft and Windows PC manufactures are using UEFI & GPT which is the newer standard for booting on Microsoft systems by default since either Windows Vista or Windows 8. Yes, Micosoft allowed existing MBR systems to continue using MBR during OS upgrades. However, new machines are default using UEFI/GPT.
Would a short message written below that only shows-up when Whole Disk option is greyed-out be clear or add to the confusion to the non-tech savvy end user?
VeraCrypt cannot encrypt entire drive due to UEFI/GPT, Microsoft's preferred boot method, has hidden partitions on the system drive that must remain unencrypted in order to boot the system.
Regarding VeraCrypt providing instructions to "remedy" the UEFI/GPT, I do not believe that VeraCrypt should be trying to give instructions of how to convert to MBR methods since this is beyond the scope of VeraCrypt's purpose. The tech savvy users will know how to search the internet to convert their systems and knowing that they going against the go forward boot strategy from Microsoft is UEFI.
Last edit: Enigma2Illusion 2019-10-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Would it not be better to just have a message.
VeraCrypt cannot encrypt entire drive due to UEFI/GPT, ( As suggested by Enigma2Illusion )
Leave it at that.
If people try work arounds, I see too many people having problems that will end up here wanting it fixed.
The average user and cmd prompts are a recipe for potential disaster.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Perhaps my message is too verbose. However, I wanted to include the reason why so people are not posting on the forums "Why is the message saying it cannot encrypt my entire system drive due to UEFI/GPT?".
Last edit: Enigma2Illusion 2019-10-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Suggestion: I don't know if this can be done, but if the RAM encryption setting is used, maybe it could be possible to allow hibernation with a workaround (with system encryption): when hibernation is invoked, the encrypted RAM contents could be decrypted and then saved onto the encrypted disk (then wiped from RAM!). Upon resuming from hibernation, the password/keys can then be encrypted in RAM again.
An attacker would never see the passwords or keys and users can still hibernate Windows.
Windows 8/10 perform a partial hibernation on shutdown to reduce boot times (fast startup) by default. Can the RAM encryption setting still be used with fast startup enabled?
Last edit: Dave 2019-10-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Enigma2Illusion I agree with your reasoning, people will come here asking why they can't do it.
The wording will have to be carefully thought out because even with the explination people will come and ask anyway and some will come and put it in that it be implimented for future versions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Using VC-Hotfix-2 (for the first test), and VC 1.24-Beta6 (all tests)
I spent the last couple of hours trying to encrypt my system OS, but kept receiving the message that the "Password, PIM or hash" was invalid during the pre-test.
"Because of BIOS requirement, the pre-boot password is typed using US keyboard layout. During the system encryption process, VeraCrypt automatically and transparently switches the keyboard to US layout in order to ensure that the password value typed will match the one typed in pre-boot mode. Thus, in order to avoid wrong password errors, one must type the password using the same keys as when creating the system encryption."
However, my assumption is that there is a bug in this.
I encrypted my OS with the following passwords:
``` -> Works
~~~ -> Fails
!!! -> Fails
@@@ -> Fails
eee -> Works
E -> Works
The passwords as shown above, are vissible in the VeraCrypt GUI
I normally use US international, but when I switch to "US" keyboard and type in the passwords in Notepad, they are still correct (as in, ! does not suddenly become a $ or so).
When typing in the password in the VC-bootloader, I used bothe the left and right shift key, but without any luck.
When typing in the password in the VC-bootloader, I also tried many other options, e.g. for "!!!" I also used 3x ~!@#$%^&*()_+-={}|[]\ and even 111, but none where correct.
My assumption is that it also does not work for #$%^&*()_+
Is it possible to have an extra option in the DOS menu, that enables showing typed in password?
It would be nice if also the password length is shown when that option is enabled. Perhaps the [shift] is registered as a character, but not shown. (however, that would not explain why EEE does work...)
Edit:
Ran one more test. Set the password to +++ using [shift] + [=] keys. Then in the VC-bootloader I failed to login using [shift] + [=] + [=] + [=], but DID successfully login using 3x [+] key on the numpad.
Last edit: JBtje 2019-10-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Using [shift] (down) + [1] + [shift] (up) in that order, 3 times in a row, results in !!! in VC-Bootloader.
So basically, the [shift] key only works for the next key, even if it is kept down.
Last edit: JBtje 2019-10-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Null: Concerning the System Favorite issue, you have certainly enabled the option "Allow only administrators to view and dismount system favorite volumes in VeraCrypt" in System Favorites configuration dialog as shown in the screenshot below. You can uncheck this option to see mounted system favorites without running VeraCrypt as Admin.
Concerning your RAM encryption question, if the cjeckbox of RAM encryption is Driver Configuration dialog is ticked, then it is enabled. This checkbox is ticked only if the corresponding registry key is present on the Windows Registry (only Admin can modify this key) and if RAM encryption is enabled in the registry and VeraCrypt is not able to use it for some reason (this will never happen in normal case), then VeraCrypt driver will provoke a Windows BSOD to stop the machine. This is a radical approach to ensure that RAM encryption is used correctly and securely.
Thanks for the clarification, this helps!
I do like the radical approach. This seems to be the safest option, especially with machines in untrusted environments.
@Mounir,
With the change to RAM encryption to prevent Windows from hibernating only occur when any of the following three conditions are met?
.
In other words, if you are not using system encryption, no passwords are currently cached and no volumes are currerntly mounted, will the machine be able to hibernate?
Last edit: Enigma2Illusion 2019-10-04
@Enigma2Illusion: If the user doesn't use system encryption, then Hibernate will be allowed even of RAM encryptioion is enabled. I will add this clarification to the Releaase Notes.
That being said, I would advice against Hibernate while RAM encryption is enabled if there are mounted volumes. Of course, it is more secure than without RAM encryption but a sophisticated attacker could still analyze the Hibernate file on the disk and do computations to retrieve the RAM encryption keys and used them to decrypt mounted volumes master keys.
Thank you Mounir for the clarification.
Would having the option in preferences to dismount all when entering power saving mode avoid the above issue?
@Enigma2Illusion:
Yes, with this option enabled, volumes will be dismounted before the Hibernate take place and so the encrypted master keys will not be written to disk. Hibernate file will not be useful to the attacker in this case.
The only attack possible is if the attacker is able to dump the RAM of a running machine which has mounted volumes, so that he can do brute force analyzis of the RAM encryption layout and try to decrypt master keys (not an easy task). There are hardware devices that can be connected using USB or firewire to a machine to perform RAM dump on live machines and that's why VeraCrypt implements a protection mechanism to erase encryption keys when a device is connected to the machine but this is only available when system encryption is used.
Maybe in the future I can add this feature to the case where systeme encryption is not used. For now, there is an entry point in VeraCrypt driver (
VC_IOCTL_EMERGENCY_CLEAR_ALL_KEYS, cf https://sourceforge.net/p/veracrypt/code/ci/master/tree/src/Driver/Ntdriver.c#l2668) that allows erasing volumes encryption keys and which requires administrative privileges. So others can implement software solutions based on this IOCTL to protect machines from rogue devices insertion.@Mounir,
Perhaps the veracrypt website should be updated also with the new changelog. I also want to point out there is a newer libzip version available 1.5.2 to update to.
Last edit: Mikael 2019-10-04
@Mikael: I have updated the changelog on the website so it should contain the clarification about Hibernate limitation.
Concerning libzip, I have also update it to version 1.5.2: https://sourceforge.net/p/veracrypt/code/ci/2f0df4af34f9299653fe00c8191f6327af73c15b/. Thank you for the reminder.
With Beta 6 it is impossible to encrypt my systemdrive complete.
I cannot click on the option. Only the systempartition.
I have tried to start Beta 6 with admin rights.
So I deinstalled it.
Edit: I have tried it now with Beta 5 and 1.23-Hotfix-2. Everywhere the same. I cannot full encrypt my systemdrive. Why?
Edit2: Ok, seems something with GPT.
Last edit: Jean Dongler 2019-10-05
Your BIOS is set to use the newer Microsoft boot method called UEFI.
https://sourceforge.net/p/veracrypt/discussion/technical/thread/08c604bdf7/#3f2a
Edit: CMD suggestions are best left for detailed walkthroughs, agreed.
In any case, UEFI causes whole drive encryption to be more difficult.
Last edit: Null 2019-10-05
This isn't true. GPT isn't just an enterprise thing anymore. Any computer that ships with Windows 10 installed is running what is called UEFI instead of BIOS. UEFI can boot legacy BIOS mode, but to sell the machine with Windows 10 they are required to boot UEFI mode. UEFI mode cannot boot from MBR. It requires GPT. So, all newer machines that come with Windows 10 pre-installed (also ones that came with Windows 8/8.1) have the primary drive in GPT format.
VeraCrypt can encrypt GPT format drives, and it isn't smart to tell people to stop using the newer UEFI over the old BIOS. Without UEFI, secure boot is also disabled. Secure boot is designed to make sure there are not any malware in the boot process. Formatting in MBR/BIOS boot means secure boot has to be disabled and malware now can inject itself in the boot process. Compromising the entire machine.
Also, with the way you laid out how to convert from GPT to MBR you forgot one critial thing. You will have to go into the UEFI and disable secure boot, and than turn on legacy BIOS boot. Following what you said will leave them with an unbootable system.
I am running a Razer Blade 15 Adv 2018 in UEFI mode with GPT formatted drive. The reason you cannot encrypt the entire drive is that the boot process needs to have a partition unencrypted to contain the boot loader. Windows BitLocker does this same thing. Format the system drive the only way you are allowed and if you have any other partitions on there, then format them seperate and load them as system favorites.
Last edit: 1210 2019-10-05
Whole drive encription (I am assuming this is every part of the drive, except the MBR, encrypted.) isn't needed. With UEFI you just encrypt each partition separately, except the EFI and any recovery partitions. Nothing is inherently insecure with partition by partition encryption. It will be the way to encrypt UEFI systems going forward, unless something changes. It is the way my two machines running with VeraCrypt are set up. The system does not store any data outside of the partitions you are encrypting. Just the GPT format information.
If I am wrong, then Mounir IDRASSI can correct me.
Jean
DO NOT reinstall Windows in BIOS/MBR setup. You need to keep the drive in GPT. It is best this way. Secure boot requires UEFI booting, which requires the drive to be in GPT. Secure boot verifies boot elements to make sure no virus/malware has injected code to completely compromise your system.
You can encrypt each partition seperately. Your drive is in GPT format, and this is necessary for Windows 10 to boot with secure boot, there is a partition, called the EFI partition, which is around 128-512 MB in size. Most of the time you cannot see this through Windows explorer. Disk Management will show this partition. This stores the bootloaders for any operating system. Windows has its own bootloader there. VeraCrypt will put one there, too. These need to be unencrypted or there is no way you can sart the system in UEFI with secure boot on. VeraCrypt's bootloader will deal with the encryption (and asks you for your password) until the Windows VeraCrypt driver takes over.
Last edit: 1210 2019-10-06
I would imagine that Jean's problem will be very common. Perhaps Veracrypt should inform the user in this situation WHY it can't encrypt the system drive? This would stop the bug reports and forum posts. Also, there could be a brief explanation of the steps to take to remedy this perhaps? It's just a suggestion, and I'm just an end-user, not a developer - although I have donated several times.
I'm glad Mounir has returned and development has picked up the pace. I'm enjoying watching the progress. Thanks everyone
It is very common and you are right. I am sure there are many people out there wondering whether or not their system truly has FDE. VC should explain why only the OS partition can be encrypted. The VC textbox should also include the ramifications and security comparisons vs whole drive encryption and steps the users can take to configure their system to enable whole drive encryption, if desired. The program has a fairly easy to understand interface execpt for this one issue. Fortunatly it's an easy fix.
I am an end user and not the developer.
Regarding the comments of having VeraCrypt provide a message about being unable to encrypt the entire system drive when UEFI is involved, can create confusion to the end user that may lead to the impression that something is wrong with the setup of their system.
Microsoft and Windows PC manufactures are using UEFI & GPT which is the newer standard for booting on Microsoft systems by default since either Windows Vista or Windows 8. Yes, Micosoft allowed existing MBR systems to continue using MBR during OS upgrades. However, new machines are default using UEFI/GPT.
Would a short message written below that only shows-up when Whole Disk option is greyed-out be clear or add to the confusion to the non-tech savvy end user?
Regarding VeraCrypt providing instructions to "remedy" the UEFI/GPT, I do not believe that VeraCrypt should be trying to give instructions of how to convert to MBR methods since this is beyond the scope of VeraCrypt's purpose. The tech savvy users will know how to search the internet to convert their systems and knowing that they going against the go forward boot strategy from Microsoft is UEFI.
Last edit: Enigma2Illusion 2019-10-06
Would it not be better to just have a message.
VeraCrypt cannot encrypt entire drive due to UEFI/GPT, ( As suggested by Enigma2Illusion )
Leave it at that.
If people try work arounds, I see too many people having problems that will end up here wanting it fixed.
The average user and cmd prompts are a recipe for potential disaster.
Perhaps my message is too verbose. However, I wanted to include the reason why so people are not posting on the forums "Why is the message saying it cannot encrypt my entire system drive due to UEFI/GPT?".
Last edit: Enigma2Illusion 2019-10-05
Suggestion: I don't know if this can be done, but if the RAM encryption setting is used, maybe it could be possible to allow hibernation with a workaround (with system encryption): when hibernation is invoked, the encrypted RAM contents could be decrypted and then saved onto the encrypted disk (then wiped from RAM!). Upon resuming from hibernation, the password/keys can then be encrypted in RAM again.
An attacker would never see the passwords or keys and users can still hibernate Windows.
Windows 8/10 perform a partial hibernation on shutdown to reduce boot times (fast startup) by default. Can the RAM encryption setting still be used with fast startup enabled?
Last edit: Dave 2019-10-05
Enigma2Illusion I agree with your reasoning, people will come here asking why they can't do it.
The wording will have to be carefully thought out because even with the explination people will come and ask anyway and some will come and put it in that it be implimented for future versions.
@Mounir,
Using VC-Hotfix-2 (for the first test), and VC 1.24-Beta6 (all tests)
I spent the last couple of hours trying to encrypt my system OS, but kept receiving the message that the "Password, PIM or hash" was invalid during the pre-test.
"Because of BIOS requirement, the pre-boot password is typed using US keyboard layout. During the system encryption process, VeraCrypt automatically and transparently switches the keyboard to US layout in order to ensure that the password value typed will match the one typed in pre-boot mode. Thus, in order to avoid wrong password errors, one must type the password using the same keys as when creating the system encryption."
However, my assumption is that there is a bug in this.
I encrypted my OS with the following passwords:
``` -> Works
~~~ -> Fails
!!! -> Fails
@@@ -> Fails
eee -> Works
E -> Works
My assumption is that it also does not work for #$%^&*()_+
Is it possible to have an extra option in the DOS menu, that enables showing typed in password?
It would be nice if also the password length is shown when that option is enabled. Perhaps the [shift] is registered as a character, but not shown. (however, that would not explain why EEE does work...)
Edit:
Ran one more test. Set the password to +++ using [shift] + [=] keys. Then in the VC-bootloader I failed to login using [shift] + [=] + [=] + [=], but DID successfully login using 3x [+] key on the numpad.
Last edit: JBtje 2019-10-06
Press F5 to show/hide password on the bootloader screen.
Thank you for the quick reply!
VC-Windows-GUI: [shift] (down) + [1] + [1] + [1] + [shift] (up) results in !!!
VC-Bootloader: [shift] (down) + [1] + [1] + [1] + [shift] (up) results in !11
Using [shift] (down) + [1] + [shift] (up) in that order, 3 times in a row, results in !!! in VC-Bootloader.
So basically, the [shift] key only works for the next key, even if it is kept down.
Last edit: JBtje 2019-10-06
You are entering the password in the VeraCrypt bootloader screen and not in the BIOS that you list in your post. Correct?