This project has moved. For the latest updates, please go here.

Batch File Drive ID Help Please

Topics: Technical Issues
Jan 23, 2015 at 2:06 PM
I have made an encrypted flash drive, it is entirely encrypted, not a volume file.

I have a keyfile on my C drive, which is also encrypted. I wanted to make a script which could be double clicked and it would mount my flash drive regardless of the drive letter assigned to it at any given time.

I understand there is some difficulty with this as VeraCrypt has no idea how to identify the drive if it is entirely encrypted.

If I made a normally formatted flash drive with an encrypted file volume I can identify the drive by volume ID.

Is it possible to either make a script or add a feature to VeraCrypt to allow the user to identify a drive if it is entirely encrypted please?

I guess the only thing which could be done is for VeraCrypt to read the hashed password section on a drive and consider that a form of ID.

The user could perhaps then make a script which used the /v switch and enter this hash instead of device number or volume name. VeraCrypt would then read the first part of each attached drive to identify it. When it discovered the matching hash then VeraCrypt would proceed to open it.
Coordinator
Mar 16, 2015 at 7:17 AM
Sorry for the late answer.

In order to mount a volume, VeraCrypt reads the the first 512 bytes and then tries to decrypt it using the given password/keyfile. You idea is to store these 512 bytes, associated them with a password/keyfile so that the next time the device is inserted, VeraCrypt will iteration through all devices, read their first 512 bytes and find the one with that matches.

Technically speaking, this is feasible but I don't like the idea of putting the header (512 bytes) and the password/keyfile at the same place and it is not good idea to implement such risky approach in VeraCrypt. I leave this to others since it is not difficult to implement outside VeraCrypt and let VeraCrypt handle only the actual mount operation.
Mar 16, 2015 at 6:50 PM
Thank you for your reply.

I am not sure of the security risk of having a drive identifier and a keyfile in the same place. I guess it does not have to be the full 512 bytes anyway?

I personally have my keyfiles in an encrypted volume, which is protected by a typed password and keyfile. Within this volume I have some basic scripts which allow me to mount my external drives quicker. However it is always difficult to remember which SATA cable each external drive must be connected to, so the decrypted drive has the correct letter.

I understand you say it is not too difficult to implement outside of your project, but it is for those with little coding experience.

Is this suggestion or request such a security issue? I suppose once an attacker has your keyfiles, contained within the same encrypted folder, it's over anyway. However I trust you know much more about this than I do.

It would be incredibly useful for myself, who admittedly has limited requirements regarding real security.

Thank you.
Coordinator
Mar 16, 2015 at 8:39 PM
If the header and the keyfile are put in the same place, an attacker can recover the master key and then keep it waiting to have access to the drive in the future. Changing the keyfile will not help as this doesn't change the master key.
On the other hand, if the attacker is able to access the keyfile at one point, he has no guarantee that this keyfile will work in the future since you can change it.

Indeed, we don't have to store the header as we only need a way to uniquely identify the drive: a SHA-512 hash of the header is enough and it can be stored instead. This is of course much safer.

As you suggested in your first post, this could implemented in the /v switch (for example, /v ID:XXXX..XX where XXX...XX is a 128 character hexadecimal string). The same can be added to the GUI in the "Auto-Mount Devices" action by adding a specific field.
Of course, one need to compute such ID in the first place: such functionality could be added to the menu displayed when you right-click on a mounted drive.

At this stage, I think this is a good proposal that is worth implementing.
You can create an entry for it in the issue tracker so it won't be forgotten (the TODO list is getting long but things get done eventually).

Thanks for the idea.
Mar 16, 2015 at 10:02 PM
"a SHA-512 hash of the header is enough and it can be stored instead."
What an elegant solution !!

I will add it to the feature request, thank you very much.