Is there a way to securely mount truecrypt/veracrypt hidden folders

929 views
Skip to first unread message

ollieo...@sigaint.org

unread,
Nov 11, 2015, 4:08:03 PM11/11/15
to qubes...@googlegroups.com
Does anyone know if there is a way to securely mount a hidden encrypted
truecrypt/veracrypt folder in Qubes? There a lot of security requirements
listed on the veracrypt website to mount hidden volumes safely.

https://veracrypt.codeplex.com/wikipage?title=Security%20Requirements%20for%20Hidden%20Volumes

Specifically, in Qubes is there a way to do something like the following:

"Download or create a "live-CD" version of your operating system (i.e. a
"live" Linux system entirely stored on and booted from a CD/DVD) that
ensures that any data written to the system volume is written to a RAM
disk. Mount hidden volumes only when such a "live-CD" system is running.
During the session, only filesystems that reside in hidden VeraCrypt
volumes may be mounted in read-write mode (outer or unencrypted
volumes/filesystems must be mounted as read-only or must not be
mounted/accessible at all). If you cannot comply with this requirement and
you are not able to ensure that applications and the operating system do
not write any sensitive data (see above) to non-hidden
volumes/filesystems, you must not mount or create hidden VeraCrypt volumes
under Linux."

timet...@gmail.com

unread,
Nov 12, 2015, 1:51:16 PM11/12/15
to qubes-users, ollieo...@sigaint.org

I do not use Veracrypt but if I wanted to follow those directions I would create a VM that had Puppy Linux installed on it as Puppy is by design entirely RAM based. It writes nothing to disk unless specifically instructed to do so at the end of the session.

However, given that this is Qubes why not simply create a separate VM with VC installed and when done with your work delete the VM. I think those directions are more for people who are not using a OS like qubes but something like Mint.

timet...@gmail.com

unread,
Nov 12, 2015, 1:52:42 PM11/12/15
to qubes-users, ollieo...@sigaint.org, timet...@gmail.com
On Thursday, November 12, 2015 at 11:51:16 AM UTC-7, timet...@gmail.com wrote:
> On Wednesday, November 11, 2015 at 2:08:03 PM UTC-7, ollieo...@sigaint.org wrote:
> I do not use Veracrypt but if I wanted to follow those directions I would create a VM that had Puppy Linux installed on it as Puppy is by design entirely RAM based. It writes nothing to disk unless specifically instructed to do so at the end of the session.
>

I should add that I know that Puppy supports TC 7.1a. I assume it will support VC but I have never tried it.

timwelter

unread,
Nov 12, 2015, 10:50:08 PM11/12/15
to qubes-users, ollieo...@sigaint.org, timet...@gmail.com

I am not sure how many or specific files written by the system between the DOM0 and various VMs but would opening the hidden partition from within a DVM work for this?  

Connor Page

unread,
Nov 13, 2015, 8:48:33 AM11/13/15
to qubes-users
Qubes does not make forensics impossible. Even disposable vms or deleted vms may have traces of the fact that a hidden partition was accessed. There is one possible solution creating snapshot of dom0 in LVM, storing it on a separate drive that later can be destroyed :) But then again a live cd is an easier and cheaper solution.

timwelter

unread,
Nov 13, 2015, 11:33:32 PM11/13/15
to qubes-users


On Friday, November 13, 2015 at 8:48:33 AM UTC-5, Connor Page wrote:
Qubes does not make forensics impossible. Even disposable vms or deleted vms may have traces of the fact that a hidden partition/files was accessed. There is one possible solution creating snapshot of dom0 in LVM, storing it on a separate drive that later can be destroyed :) But then again a live cd is an easier and cheaper solution.

 "Qubes may have traces" Do we know  what "pertinent" traces that using DVM to access another data partition leaves behind? Things that would show data itself not just indicate that there is a hidden partition.  Any reasonably knowledgeable person with proper forensic tools will be able to scan a drive and see that it has a hidden partition/files (headerless) or not.  So I think at the high level the whole idea of hidden partition, sten, etc is nothing but a smoke screen and if anything can lead to even higher levels of suspicion. Plenty of people have encrypted data for main stream reasons but once you try to get sneaky this raises flags and since its not effective at that level whats the point.  Yes against low level attacks it can add benefit.  But point is it being hidden is not offering it any protection against someone that is smart enough to start doing serious forensics on the machine.

I would start with the fact that they will know there is a partition and possibly data there.  So then what are we left with?  More a legal question of what they can prove or thus compel from you legally.  This of course will vary greatly from gov to gov. 


Without knowing anything about what Qubes leaves as traces for data accessed via DVM from drive space the best answer right now could be the live distro route. But then isn't finding out out about what Qubes logs and leaves and how possible it would be to use in this scenario the whole point of the opening post/question? 

Marek Marczykowski-Górecki

unread,
Nov 14, 2015, 7:54:19 AM11/14/15
to timwelter, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Similar discussion / info is here:
https://github.com/QubesOS/qubes-issues/issues/904

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJWRy71AAoJENuP0xzK19csEHcH/AgxE4cN79K9QjtP7P+6cIvt
c3nvYN4VviAsOUqTbKY32kJfOtnRAmEmS6eZsQrQlg3UuzTjAq4pFsRb6LRsVrUQ
jLZ/y0rShWeUaJFK5E7rtAVevpTwUXc1jGINqJ5+fdyhmgmhORskrwgpKrm2SdPP
MmKelQkALBKuGrpsKzPthAIcfW/3qWc8p8ZcDtVpyxBTpkFSCi6kPFlrGAerhEHa
oYEGVLfKj5VQRWd476/34zWt7tYYhFHQQCYPkzohFrAfIJRjROM03R787kmIAY/L
KrTDEdlUoethOdVyt7+zyBbDgeZ+zQUpd7SsM7TatWLF5UVOD6I06K9RgAXid2A=
=Jju6
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages