2

I am trying to understand the benefits of a PKCS #11 keyfile stored on a smartcard such as a YubiKey with regards to Veracrypt volumes. Am I correct that the file will be taken off of the hardware device to be used? If so, this would seem to expose it to software running on the system therefore negating most or all of the benefits of a hardware token.

Am I missing something?

3

This question is indeed a very good one. I'm no expert but since nobody is jumping in (I guess because questions that already have at least one answer are less attractive).

Florian's answer to this question is just a boilerplate of how things are supposed to work with PKCS11 but not at all the way the standard was implemented in Veracrypt.

As the developers acknowledged recently here Veracrypt does not support asymmetric keys. If you try to use an RSA key from a smartcard as a keyfile the window "Select Security Token Keyfiles" will come out empty. Quoting from the link:

...I also have the idea of modifying VeraCrypt format in order to support using Asymmetric keys (RSA or Elliptic Curve) that are stored on such cards or tokens: these keys will be used to decrypt the header volumes instead of relaying [sic] on the password. This will provide stronger security and but it also requires a big development effort while at the same time targeting a very small number of potential users...

That's that then, private keys (CKO_PRIVATE_KEY) are out of the question, what about symmetric keys (CKO_SECRET_KEY)? Nope, that's not supported either.

How exactly is PKCS11 supported then? Well... if you take a look at the code: SecurityToken.cpp you'll notice on line 215 a reference to CKO_DATA. Let's go take a look at the PKCS11 standard to find out what that is:

Data objects (object class CKO_DATA) hold information defined by an application. Other than providing access to a data objects, Cryptoki does not attach any special meaning to a data object.

So, if it's not a key (public, private, or secret) and it's not a certificate it will be a data object (no strings or special meaning attached). I don't know exactly what was the original idea behind this kind of object, what I know is they ended up being used for different things, the one I've seen most frequently is to store personal data. One example could be your name and address on a European national eID card or your picture on an ICAO compliant electronic passport.

Is this CKO_DATA object supposed to be used to hold keys or passwords? I don't think so because if you do that you are basically giving up all cryptographic features of the smartcard or token.

Is this better than storing your keys on your disk unprotected and unencrypted? I guess it is, at least on most tokens your keys will be password protected. I would agree it is the same as storing your keys on a password-protected non-cryptographic USB drive.

On this topic, I'm sure you will find all kinds of opinions. There was an interesting debate on the opensc github some time ago.

1
  • Deleted my answer since it was an inaccurate assumption. The implementation seems to hold the answer to the question, for which ultimately the implementer or someone going through the source code (open source) could figure out the rationale & security implications for using a PKCS#11 keyfile without supporting asymmetrical keys. Sep 8 at 11:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.