Assume I have an external USB hard disk and I created a full VeraCrypt volume without inner, hidden partition on it.
Can I later (=months later) decide to add such a second, inner, hidden partition/volume or is this only possible at creation time of the first, outer volume?
How do I do this in detail?
What about the opposite operation: Can I later delete the second, inner, hidden partition/volume without destroying the first, outer container (and its content)?
Thomas
Last edit: Thomas 2018-01-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You can always add a hidden volume into an existing volume. Just launch the volume creation wizard, select "Encrypt a non-system partition/drive", then choose "Hidden VeraCrypt Volume" and finally select "Direct Mode". After this, select your device, type its password and then VeraCrypt will analyze its content to see if there is enough space to create a hidden volume.
If everything is OK, you will be presented by a the usual hidden volume wizard dialogs that will indicate the space available and that will enable you to choose the encryption parameters.
Please note that in order to create a hidden volume, VeraCrypt need to find enough free space at the end of the drive and this sometimes is not possible even if the volume indicate a lot of free space: the cause is that the filesystem (like NTFS) may have written data at the end of the drive at some point and even if you delete many files/folders, existing data may remain at the end of the drive which will block the creation of a hidden volume.
That's why it is more reliable to create a hidden volume while no data has been written to the outer/normal volume.
Concerning your question about deleting a hidden volume, you don't need to do that. There is no way to know if a hidden volume exists and you can use the outer volume as a normal volume without bothering about the hidden volume. At some point, if you make the outer volume full of data, the header of the hidden volume will be overwritten and thus the hidden volume can never be mounted again.
If you really want to avoid the hidden volume being access with its password, the easiest way is to change its password to a random value and then discard this new password so that it will not be accessible by anyone.
Voilà voilà...I hope this will help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is not true. I cannot stress enough how not true this is. I have been trying to awaken people to the dangers of the "plausible deniability" feature first with TrueCrypt and now VeraCrypt for some time.
When you have an outer volume with a hidden inner volume, one of two things has to occur. The outer partition has to be used only very rarely, or else it is used regularly but to protect the inner volume data it has to be mounted in such a way as to never write to the inner volume's area.
Rarely used outer volume:
First of all, a rarely used outer volume, encrypted with VeraCrypt that includes "plausible deniability" inner hidden volumes as a feature is itself a red flag for a hidden volume. But other than that, in a situation where the outer volume is rarely used, the inner volume will still be used to read from and write to. It is possible to determine accurately how often parts of a drive are written to. This is especially true of solid state devices where wear levelling remaps occur on frequently written to areas, but it is also the case with traditional magnetic media from data written for ECC (some drives have a write serial number as part of the error detection and can be used to actually track the order of writes on a drive), and SMART (which remaps based on error correction rates much like SSDs do). With magnetic media, the higher the density the more the drive tends to rely on ECC and SMART remapping. Thus with a rarely used outer partition, the file datestamps, and filesystem structures of the outer volume say that nothing happens on that partition, but this then is at odds with the evidence that the device is physically written to often and recently.
Protected outer volume:
If you mount the outer volume with inner volume protection, it prevents the outer volume from being written to in the locations where the inner volume is located. The OS is not aware of this protection, and this ends up creating filesystem problems on the outer partition that are easily detectable. It also leaves a very sharply defined black hole in the outer volume where data is never aparrently written to, which is also a big red flag. Also, the same evidence as mentioned in rarely used outer volumes can be used to determine that the inner volume area actually does get written to a great deal, which will be at odds with what the outer partition is telling you.
As mentioned above, simply the usage of an encryption system that includes plausible deniability as a major feature is a huge red flag, and makes something warrant further investigation. Do not rely on it to prevent detection of an encrypted volume.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you Kurt for pointing out these issues. You are bringing up very important points that are crucial for those who rely on the hidden volume feature.
VeraCrypt documentation tries to cover this subject by outlining different security requirements and precautions. Specifically, the documentation advises against using SSD drive (wear level feature). As for magnetic drives, indeed some models can have journaling like system for monitoring purposes and this is also warned about in the documentation. However, such systems are limited in capacity and it is possible to workaround them by having a good usage strategy (like always writing to the inner volume whenever a write operation occurs in hidden part).
Concerning the information leak when hidden volule protection is triggered, this is also described in the documentation and VeraCrypt tries to protect against it by making the outer volume write protected as soon as the protection is triggered. But we need to update the documentation in order to indicate that we can not guarantee that the filesystem is free of inconsistencies since we can't guarantee if the OS will rollback properly the failed write operation. Probably, we will add a note to advice to discard a volume once the hidden protection mechanism is triggered and to move its content to a new volume for better plausible deniability.
To my knowledge, such filesystem inconsistencies are more common to NTFS than FAT32 or exFAT but a deeper study is needed to estime better the leak for each filesystem type. More generally, it is advises to use FAT32 or exFAT instead of NTFS for outer volume in order to lower the risk of triggering the hidden volume protection mechanism (If asked by usage of exFAT or FAT32, the user can argue that it is for better compatibility across operating systems), combined with definition of a limit for the amount of data stored in outer volume that should not be exceeded to avoid triggering the hidden volume protection mechanism.
As a conclusion, hidden volumes usage requires many precautions in order to avoid its detection. But as you said, even just using VeraCrypt can be suspicious is some contexts. In this case, it is better to avoid using VeraCrypt and switch to a combinaition of steganography and standard encryption.
Last edit: Mounir IDRASSI 2018-01-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I know this topic is over a year old but the discussion is such that I feel it's important to point out a fact that is often overlooked when discussing hidden volume "vulnerabilities".
None of the issues that kfitzer brought up undermine "Plausible Deniability”. None.
Plausible Deniability does not mean there is zero lack of evidence of knowledge of the existence of something, or some event. All that is needed to maintain plausible deniability is a lack of direct conclusive evidence that proves knowledge of existence or events etc…
Sectors not being written to… a lawyer would ask kfitzer “Is there any other software, programs, or malfunctions in hardware and software that could cause drive sectors to remain underutilized, or not utilized at all? Immediately kfitzer would have to answer yes, and that answer would provide Plausible Deniability.
And that same logic applies to nearly all of the so-called vulnerabilities of hidden volume plausible deniability.
Just because you suspect something, or see some evidence that a hidden volume may exist or may have existed, unless you can mount it you don’t have a leg to stand on in court. All the “warranted further investigation” in the world will not change that legal fact.
You come into court and say “We are 95% certain a hidden volume exists on that drive…” and the lawyer will ask “Is it possible that it existed at one time, but had been damaged so it can no longer be decrypted?” Again, the answer would be yes, and plausible deniability of the PW/Keys that will open that data is maintained. Defense could either produce any fabricated pass (that of course will not work) or simply claim the password and keys were disposed of, when the volume became corrupted, because they were no longer needed.
Bottom line is, in the U.S. the goal pf PD is to avoid rotting in jail for contempt of court for not revealing the PW/Key(s) to a volume that may contain data that you do not want revealed. All the expert investigation in the world will not prove definitively that a hidden volume exists, or is capable of being decrypted, and more importantly it will not prove that you have direct, current knowledge of how to access that volume.
The only real concern here in the U.S. in terms of hidden volumes is data being revealed accidentally, side-attacks, or “if” in fact data in a hidden volume can be “hacked” into.
As of PD in other countries with different legal systems and/or brutal political establishments I cannot speak to those issues.
Just my 2 cents.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Assume I have an external USB hard disk and I created a full VeraCrypt volume without inner, hidden partition on it.
Can I later (=months later) decide to add such a second, inner, hidden partition/volume or is this only possible at creation time of the first, outer volume?
How do I do this in detail?
What about the opposite operation: Can I later delete the second, inner, hidden partition/volume without destroying the first, outer container (and its content)?
Thomas
Last edit: Thomas 2018-01-07
Hi,
You can always add a hidden volume into an existing volume. Just launch the volume creation wizard, select "Encrypt a non-system partition/drive", then choose "Hidden VeraCrypt Volume" and finally select "Direct Mode". After this, select your device, type its password and then VeraCrypt will analyze its content to see if there is enough space to create a hidden volume.
If everything is OK, you will be presented by a the usual hidden volume wizard dialogs that will indicate the space available and that will enable you to choose the encryption parameters.
Please note that in order to create a hidden volume, VeraCrypt need to find enough free space at the end of the drive and this sometimes is not possible even if the volume indicate a lot of free space: the cause is that the filesystem (like NTFS) may have written data at the end of the drive at some point and even if you delete many files/folders, existing data may remain at the end of the drive which will block the creation of a hidden volume.
That's why it is more reliable to create a hidden volume while no data has been written to the outer/normal volume.
Concerning your question about deleting a hidden volume, you don't need to do that. There is no way to know if a hidden volume exists and you can use the outer volume as a normal volume without bothering about the hidden volume. At some point, if you make the outer volume full of data, the header of the hidden volume will be overwritten and thus the hidden volume can never be mounted again.
If you really want to avoid the hidden volume being access with its password, the easiest way is to change its password to a random value and then discard this new password so that it will not be accessible by anyone.
Voilà voilà...I hope this will help.
This is not true. I cannot stress enough how not true this is. I have been trying to awaken people to the dangers of the "plausible deniability" feature first with TrueCrypt and now VeraCrypt for some time.
When you have an outer volume with a hidden inner volume, one of two things has to occur. The outer partition has to be used only very rarely, or else it is used regularly but to protect the inner volume data it has to be mounted in such a way as to never write to the inner volume's area.
Rarely used outer volume:
First of all, a rarely used outer volume, encrypted with VeraCrypt that includes "plausible deniability" inner hidden volumes as a feature is itself a red flag for a hidden volume. But other than that, in a situation where the outer volume is rarely used, the inner volume will still be used to read from and write to. It is possible to determine accurately how often parts of a drive are written to. This is especially true of solid state devices where wear levelling remaps occur on frequently written to areas, but it is also the case with traditional magnetic media from data written for ECC (some drives have a write serial number as part of the error detection and can be used to actually track the order of writes on a drive), and SMART (which remaps based on error correction rates much like SSDs do). With magnetic media, the higher the density the more the drive tends to rely on ECC and SMART remapping. Thus with a rarely used outer partition, the file datestamps, and filesystem structures of the outer volume say that nothing happens on that partition, but this then is at odds with the evidence that the device is physically written to often and recently.
Protected outer volume:
If you mount the outer volume with inner volume protection, it prevents the outer volume from being written to in the locations where the inner volume is located. The OS is not aware of this protection, and this ends up creating filesystem problems on the outer partition that are easily detectable. It also leaves a very sharply defined black hole in the outer volume where data is never aparrently written to, which is also a big red flag. Also, the same evidence as mentioned in rarely used outer volumes can be used to determine that the inner volume area actually does get written to a great deal, which will be at odds with what the outer partition is telling you.
As mentioned above, simply the usage of an encryption system that includes plausible deniability as a major feature is a huge red flag, and makes something warrant further investigation. Do not rely on it to prevent detection of an encrypted volume.
Thank you Kurt for pointing out these issues. You are bringing up very important points that are crucial for those who rely on the hidden volume feature.
VeraCrypt documentation tries to cover this subject by outlining different security requirements and precautions. Specifically, the documentation advises against using SSD drive (wear level feature). As for magnetic drives, indeed some models can have journaling like system for monitoring purposes and this is also warned about in the documentation. However, such systems are limited in capacity and it is possible to workaround them by having a good usage strategy (like always writing to the inner volume whenever a write operation occurs in hidden part).
Concerning the information leak when hidden volule protection is triggered, this is also described in the documentation and VeraCrypt tries to protect against it by making the outer volume write protected as soon as the protection is triggered. But we need to update the documentation in order to indicate that we can not guarantee that the filesystem is free of inconsistencies since we can't guarantee if the OS will rollback properly the failed write operation. Probably, we will add a note to advice to discard a volume once the hidden protection mechanism is triggered and to move its content to a new volume for better plausible deniability.
To my knowledge, such filesystem inconsistencies are more common to NTFS than FAT32 or exFAT but a deeper study is needed to estime better the leak for each filesystem type. More generally, it is advises to use FAT32 or exFAT instead of NTFS for outer volume in order to lower the risk of triggering the hidden volume protection mechanism (If asked by usage of exFAT or FAT32, the user can argue that it is for better compatibility across operating systems), combined with definition of a limit for the amount of data stored in outer volume that should not be exceeded to avoid triggering the hidden volume protection mechanism.
As a conclusion, hidden volumes usage requires many precautions in order to avoid its detection. But as you said, even just using VeraCrypt can be suspicious is some contexts. In this case, it is better to avoid using VeraCrypt and switch to a combinaition of steganography and standard encryption.
Last edit: Mounir IDRASSI 2018-01-23
Hello sorry to post on this issue.
It's because I want do the same but I don't find the "Direct Mode" on Linux version.
I use veracrypt version 1.22
Did I miss something ?
@idrassi @kfitzner
I know this topic is over a year old but the discussion is such that I feel it's important to point out a fact that is often overlooked when discussing hidden volume "vulnerabilities".
None of the issues that kfitzer brought up undermine "Plausible Deniability”. None.
Plausible Deniability does not mean there is zero lack of evidence of knowledge of the existence of something, or some event. All that is needed to maintain plausible deniability is a lack of direct conclusive evidence that proves knowledge of existence or events etc…
Sectors not being written to… a lawyer would ask kfitzer “Is there any other software, programs, or malfunctions in hardware and software that could cause drive sectors to remain underutilized, or not utilized at all? Immediately kfitzer would have to answer yes, and that answer would provide Plausible Deniability.
And that same logic applies to nearly all of the so-called vulnerabilities of hidden volume plausible deniability.
Just because you suspect something, or see some evidence that a hidden volume may exist or may have existed, unless you can mount it you don’t have a leg to stand on in court. All the “warranted further investigation” in the world will not change that legal fact.
You come into court and say “We are 95% certain a hidden volume exists on that drive…” and the lawyer will ask “Is it possible that it existed at one time, but had been damaged so it can no longer be decrypted?” Again, the answer would be yes, and plausible deniability of the PW/Keys that will open that data is maintained. Defense could either produce any fabricated pass (that of course will not work) or simply claim the password and keys were disposed of, when the volume became corrupted, because they were no longer needed.
Bottom line is, in the U.S. the goal pf PD is to avoid rotting in jail for contempt of court for not revealing the PW/Key(s) to a volume that may contain data that you do not want revealed. All the expert investigation in the world will not prove definitively that a hidden volume exists, or is capable of being decrypted, and more importantly it will not prove that you have direct, current knowledge of how to access that volume.
The only real concern here in the U.S. in terms of hidden volumes is data being revealed accidentally, side-attacks, or “if” in fact data in a hidden volume can be “hacked” into.
As of PD in other countries with different legal systems and/or brutal political establishments I cannot speak to those issues.
Just my 2 cents.