Veracrypt and additional security by Yubikey
Open source disk encryption with strong security for the Paranoid
Brought to you by:
idrassi
Menu
▾
▴
Dear development team,
having Veracrypt as a replacement for TrueCrypt is GREAT, and I started to
migrate my TrueCrypt files/volumes to the new platform.
To add more security, what about making use of Yubikey
(https://www.yubico.com/)? This device is supported by PasswordSafe, and
enforces a kind of two factor authentication: You need to know a passphrase,
and to have the personalized Yubikey device.
The start page looks like this (when the Yubikey devices is plugged in):
We use Yubikey to secure the PasswordSafe and it would be great to have the
same mechanism when using Veracrypt.
Looking forward to hear from you - hopefully a positive comment -
Carl Weber
Just to clarify, Yubikey can already be used to enter the password of a VeraCrypt volume or during pre-boot authentication (http://www.yubico.com/wp-content/uploads/2012/10/TrueCrypt-v1.1.pdf, applies to TrueCrypt but also valid for VeraCrypt)
Your request is for having a second password for VeraCrypt that will entered through Yubikey, the first password being entered manually.
VeraCrypt already supports a second factor authentication through the use of keyfiles. So, since their can be only one password per volume, the password generated by Yubikey could be considered as a keyfile.
That being said, VeraCrypt only integrates standard technologies and specifications, and supporting a specific technology from a specific manufacturer is not the policy of VeraCrypt. Moreover, there are other competing technologies that can also be considered. Thus, unless there is a specific sponsoring from Yubico or others to get this technology integrated directly into VeraCrypt, there will be no explicit support for Yubikey in VeraCrypt.
In the mean time, and as explained above, users can use Yubikey as a way for enter secure password in VeraCrypt.
Last edit: Mounir IDRASSI 2015-03-01
Yubikeys can only be considered as a keyfile, if the static password mode is used, as it is already possible for TrueCrypt and VeraCrypt. One time passwords are different, since they are not static. So the request above is not about entering a second password, but about verifying that a unique authentication device is present, which will return different codes upon different requests.
While Yubico OTP mode is actually a proprietary technology, yubikeys do also offer open standards like OATH TOTP/HOTP. I believe that HMAC-SHA1 challenge response mode is also an open standard which is used by the above mentioned Password Safe program (passwordsafe is open source). I think this could actually be a nice security improvement, making even shorter (and easier to remember) passwords pretty safe. However, I understand that your time is limited and you might consider other things to be more important to implement than that.
best regards
xenon
Thank you Xenon for this comment.
OTP is not adapted to disk encryption as it is a mechanism designed for dynamic authentication which is completely different from the requirement of encryption (static encryption key).
In order for any mechanism to be included in disk encryption, it must ultimately provide static information that will be used to derive a key used to decrypt the master key. By design, OTP doesn't have this capability.
One can imagine a scheme where OTP is used to authenticate to a "key server" that will provide the static keyfile used to unlock the encrypted disk/volume. This would require an online service integrated to a local software used to call VeraCrypt to perform the operation.
Such scheme is outside the scope of VeraCrypt and it already provides the necessary command line interface that can be used to integrate its functionality with such scheme. Of course, this command line interface can be enhanced and one can also imagine a VeraCrypt API can be easily used by programmers to develop such integration.
Hello Mounir,
thanks for your response. You are right, I understand that OTP methods are generally not designed for encryption, and especially when having environments with very high security requirements, you probably won't have any connection to online services as well.
The HMAC-SHA1 challenge response mode used for PasswordSafe is also based on a static secret key, and this could probably work this way:
VeraCrypt would use your password to decrypt the key, send a randomly created challenge code to the yubikey and then validate the returned response. Additionally, as a user option, you could register yubikeys with their unique serial number with your encrypted volume. Also, may be as another option, you could check for the presence of the key repeatedly after a time interval of your choice and close the encrypted volume as soon as the key is removed. And of course, there would be no hint that such a key is required when trying to open a volume without having a key plugged in. I don't know how much effort such an implementation would require, but maybe Yubico would be even willing to sponsor you. They are always looking for more applications using their products. They still offer a yubikey bundle preprogrammed for PasswordSafe. However, they don't advertize, probably because they also offer a LastPass bundle (commercial). But perhaps they would also put VeraCrypt on their website if it would offer additional yubikey support, helping to make VeraCrypt more popular. This is all just for consideration.
I like the VeraCrypt project because I find open source disk encryption software so important, and it should be available for everyone now and in the years to come. Considering what you have achieved already, it looks really promising (and that's why I already donated this weekend). If you set up a crowdfunding campaign, (not necessarily for an audit only, could also be for development support) I will support it too as soon as I know about it.
Best regards
Xenon
Yubikey are a member of the Fido alliance & newer keys support the v1 specification, which is an open standard.
Details https://www.yubico.com/applications/fido/ and https://fidoalliance.org/specifications/download
Potentially may be of interest, in regards to the comment above regarding supporting open standards only / not vendor proprietary (which I'd support).
However, one point of caution / potential reason to hold off supporting for now, Microsoft (a member of Fido alliance) have stated that they've proposed changes to the specification & stated that Windows 10 will support the v2 spec... beyond that, there hasn't been any additional announcement, but the spec listed above may change somewhat as a result.
Kind regards
Sleepy
Thank you Xenon and Sleepy for these valuable information.
Indeed, outside the scope of a specific sponsoring, supporting an open standard is the way to go. That being said, my limited understanding of Fido indicates that it is based on public key cryptography and it requires a registration phase. I'll have to think how to transform this to a mechanism for deriving a unique encryption/decryption key like what Xenon described in his previous post.
One thing that must be kept in mind is that VeraCrypt is open source and as such there are other implementation that can decrypt VeraCrypt volumes. Thus, the support of any device requires the implementation of a key derivation mechanism and we can't only rely on authentication since this can be bypassed by other VeraCrypt format implementations.
Last edit: Mounir IDRASSI 2015-03-10
Hello,
What I'm trying to do is to use my Yubico NEO PIV applet with OpenSC as a PKCS11 token to force the need of my Yubikey to decrypt my Volume.
However, when I try to use the opensc-pkcs11 library with Yubico inside VeraCrypt, I have an error saying "function not supported". I can't seem to understand if the problem come from VeraCrypt or OpenSC or the Yubico PIV applet.
Can you help me on this problem ?
Hi,
On which operation the error "function not supported" is returned? During login or when you want to import key files?
I don't know the applet you are using but VeraCrypt is compatible with any PKCS#11 implementation that supports private Data Objects (CKO_DATA type, CKA_PRIVATE attribute).
If the error happens when you try to import key files, then it may be caused by the fact that CKO_DATA are not supported in your case. OpenSC supports CKO_DATA but it works only if the module of the target card also supports CKO_DATA. I have no knowldge on PIV module implementation in OpenSC but it is possible that PIV doesn't support Data objects.
If the error happens during login, then this is very strange...You can use my tool CryptokiManager in this case in order to manually load the PKCS11 and perform login and objects find. Here is its link: https://www.idrix.fr/Root/content/category/5/23/40/
Do you git the same error with this tool? If yes, on which operation?
Yubikey (neo) is a solution without ability to update firmware, with security issues in the firmware. Interesting...
https://developers.yubico.com/ykneo-openpgp/SecurityAdvisory%202015-04-14.html