This project has moved and is read-only. For the latest updates, please go here.

Hidden Dual Use

Topics: Feature Requests
Feb 11, 2016 at 5:00 PM
I've been thinking about the implementation of Hidden volumes for some time now and the more I think about it the more there seems to be an oddity that comes up. The outer volume is intended to have "fake" files for the purpose of plausible deniability, and the Hidden volume is meant to house your sensitive documents.

Yet to me it seems like there is a obvious flaw in the way the current system handles Hidden volume protection in that it simply starts pushing errors when you "hit" the hidden volume layer (if protected).

What I don't quite understand is what is the reasoning behind not simply mounting the volume at whatever size the outer volume is rather than mounting the whole volume. For example if you have a 1 GB container and 500MB of it is Hidden and 500MB is not, why can it not mount the outer volume as a 500MB container if the hidden volume is protected, similarly the best use case would be that if the hidden volume is protected, both volumes are mounted and separated. E.g two 500MB volumes.

This would also have the added benefit that you could actively use both as necessary, which leads me to the potential use case behind plausible deniability in that if you have a 1GB container and only a few hundred megs is used, the common question would be why is there 800mb encrypted that isn't used? Then you could reinforce that question by checking how often the files on the outer volume are accessed/modified. If they're old and not commonly accessed/modified it's a pretty safe bet there is a hidden volume due to the fact that currently the "safety" mechanism discourages an actively used outer volume. In my opinion the best plausible deniability would be if you could actively use both the outer and inner volumes so to a potential attacker there is nothing particularly obvious about it.

I understand that this may not be practical or possible, it is just something I've thought about on and off for awhile with relation to hidden volumes. They're great but as I said, there are questions that come up from an attacker point of view that would suggest a hidden volume. The best way to avoid that question would be to allow the outer volume to be used PROVIDED that the Hidden volume is protected. (Or instead of calling it protected it could just be "mount hidden volume as well").

Comments? Thoughts?
Feb 11, 2016 at 5:32 PM
To summarize your idea, if I mount a volume and using the option button to protect the hidden volume, VeraCrypt should mount both outer and hidden volumes to different letters.

The problem I see with this approach is you may not want to have the hidden volume mounted and its files accessible to merely protect the hidden volume from being overwritten by files in the outer volume.
Feb 12, 2016 at 4:58 AM
Enigma2Illusion wrote:
To summarize your idea, if I mount a volume and using the option button to protect the hidden volume, VeraCrypt should mount both outer and hidden volumes to different letters.

The problem I see with this approach is you may not want to have the hidden volume mounted and its files accessible to merely protect the hidden volume from being overwritten by files in the outer volume.
That is very true, but in that case you could merely leave the protection option and not select a letter. That way the Hidden volume is not mounted, and the behaviour is identical to the current implementation.

My main purpose behind the post is the fact that as it stands it is discouraged to actively "use" the outer volume and from my perspective that could give an "attacker" a good reason to suspect the existence of a hidden volume.

Given how containers and volumes currently work they seem to be intended to be usable and not strictly for archiving purposes for data that never changes, I know I have a lot of containers and volumes that I use as normal drives where I often use/write/add/change data to them. The current implementation of Hidden volumes makes that impractical if not impossible to do with an Outer volume. It isn't so much of an issue if your data is unchanging or you use read only the majority of the time (Which I do for some of my archive/personal volumes).

It would just be nice to have as an option, not necessarily removing the current implementation for those who like you said might not want to expose their hidden volume at all.
Feb 12, 2016 at 3:34 PM
Another inherent danger with your request to mounting both outer and hidden volumes at the same time, a user could make a mistake of creating or copying sensitive files accidentally to the outer volume when they meant to use the hidden volume.

Just like the hidden OS, the manual instructs the user to use the decoy OS in order to give plausible deniability. The same is true for volumes using the hidden volume feature. To reduce the effort of changing data in the outer volume, you could put non-sensitive archival data or static data in the outer volume. Examples would be your music files or family photos, etc.

https://veracrypt.codeplex.com/wikipage?title=Plausible%20Deniability
Feb 12, 2016 at 4:40 PM
Enigma2Illusion wrote:
Another inherent danger with your request to mounting both outer and hidden volumes at the same time, a user could make a mistake of creating or copying sensitive files accidentally to the outer volume when they meant to use the hidden volume.

Just like the hidden OS, the manual instructs the user to use the decoy OS in order to give plausible deniability. The same is true for volumes using the hidden volume feature. To reduce the effort of changing data in the outer volume, you could put non-sensitive archival data or static data in the outer volume. Examples would be your music files or family photos, etc.

https://veracrypt.codeplex.com/wikipage?title=Plausible%20Deniability
But the very nature of the data on the outer volume "needing" to remain static is exactly why plausible deniability is somewhat compromised. I get the inherent user error potential but I see it as somewhat of a contradictory issue. If you as a user accidentially mistake your outer volume for your hidden volume that suggests bigger concerns than what any encryption will protect you from.

If I were an attacker and I knew a volume was encrypted and I forced a person to reveal the password to a decoy volume, I'd analyze the usage of the data on that volume. If it appeared to be consistently static, I would then have probable cause to believe there is a hidden volume. Of course it cannot be proven, but given that laws are becoming increasingly aggressive with regards to forcing people to reveal encryption passwords I think steps need to be taken to increase the capability or at least re-evaluate the potential pros and cons of the proposal I've put forth.

To reiterate the initial proposal.
  1. Keep the "hidden volume protection" as it is now.
  2. Add a second option that opens up when using the hidden volume protection which if checked shows a drop down box of available letters to use, if that option is selected new behaviour occurs in that both the hidden volume and the outer volume are mounted (The hidden volume mounted on the selected letter on that dialog). What this would do is provide you with the outer volume that only shows the free space that it actually has. The only way I can see implementing it properly would be to simulate a ghost file of the hidden volume taking up the space that the hidden volume actually takes up. That way both volumes can be used independently of each other. The outer volume would appear with whatever size "free" that it has free with a "HiddenVolume" file that takes up the space of the Hidden volume. In a way it would actually be similar to how it would look if you mounted a volume within a volume.
Then you could utilize both actively which would provide more plausible deniability as there would be no easy way of determining the possibility of a hidden volume, which as I said before becomes somewhat apparent when you realize as an attacker that all the data on the outer volume that the victim provided the password too is relatively static.

While I do admit there is a slight risk of data leakage as you said Enigma2Illusion, the main issue with that logic is that security really needs to be put on the user. Security measures shouldn't be built to be idiot-proof. If the choice is usability, and enhancing security for people who know what they're doing while slightly increasing the risk of people who are careless and don't know what they're doing, I'd choose security. If you're going to these lengths to secure data from potential attackers, then you as the user should know enough about the system you're using to use it properly.