PKCS#11: Yubikey 4, can't sign certificates with pin-policy=always

[Forst]

I have a Yubikey 4, which among other things supports PIV with RSA and ECDSA keys. These can be used in xca via PKCS#11 through either OpenSC or YKCS11 libraries.

I'm often getting the following error when trying to create a certificate using the root key/cert pair stored on the token:

The following error occurred:
(8pki_x509[]:Test EC Sub-CA)
error:0D0DC006:asn1 encoding routines:ASN1_item_sign_ctx:EVP lib

(pki_x509.cpp:586)

I can't yet get a consistent reason as to why this happens. Once I somehow managed to make it all work with different key types, but now it's not working no matter what I do (you might've noticed multiple edits to this issue, that's the reason why).

UPD: I think I found it! It depends on the PIN policy for the given key. For all tests below I've set touch-policy (i.e. the requirement to press the token button after PIN entry) to always for all keys tested.

Cold token (just inserted)

PIN policy	PIN asked	Touch asked	Worked
never	once	once	yes
once	once	once	yes
always	once	twice	no

Hot token (keys were already used)

PIN policy	PIN asked	Touch asked	Worked
never	no	once	yes
once	no	once	yes
always	no	twice	no

[chris2511]

Is it possible for you to provide a token with middleware for debugging here?

One great debugging-tool is the opensc pkcs11-spy library. It is a "ManInTheMiddle-library" between the application and the destination library, logging all calls and replies to the console.

Start XCA in the Terminal as follows: PKCS11SPY=/usr/local/lib/libykcs11.dylib /Applications/xca.app/Contents/MacOS/xca open your database, open the preferences and remove the libykcs11.dylib from the settings and load /usr/local/lib/pkcs11-spy.so instead.

Now all PKCS#11 API calls are logged to the console. Maybe this will give more insight. You will also see XCA logging its database actions.

In any case, a Yubikey4 is highly appreciated for testing and playing around :-)

[Forst]

I've collected some logs here: https://gist.github.com/Forst/6d6504da19f51f6ef802e9de8009b847

What I did for both PIN policies:

• Generate a new keypair and cert with yubico-piv-tool in slot 82
• Start xca and import those into the database
• Generate a test EC key, which is to be signed
• Sign it as a sub-CA

I'm using OpenSC, since YKCS11 shows errors for some of my certificates and ends up not displaying those, this is a topic for investigation for some other day :)

The problem is clearly here in xca.pin-always.log:

111: C_Sign
2018-06-28 14:28:31.280
[in] hSession = 0x7f90ff8310f0
[in] pData[ulDataLen] 00007ffee5b3ec20 / 32
    00000000  E2 29 35 19 C8 A9 DA 8B 25 E9 27 F1 EB F9 BA C9  .)5.....%.'.....
    00000010  57 F8 A3 4B 84 9D EA D0 8B C1 3E 56 9C DA 7A 5B  W..K......>V..z[
Returned:  257 CKR_USER_NOT_LOGGED_IN
Error: C_Sign(init): CKR_USER_NOT_LOGGED_IN
OpenSSL error (pki_x509.cpp:586) : error:0D0DC006:asn1 encoding routines:ASN1_item_sign_ctx:EVP lib
"Destructor(0) Transaction: Rollback Level 0, E:1 "

[chris2511]

In the same log we also see the successful

105: C_Login
2018-06-28 14:28:31.264
[in] hSession = 0x7f90ff8310f0
[in] userType = CKU_USER
[in] pPin[ulPinLen] 00007f90ffb93028 / <deleted>
    <deleted>
Returned: 0 CKR_OK

for this session. There is nothing more XCA can do. I am pretty sure it has to do with the touch asked feature.

I think this token looks interesting enough to buy one....

[Forst]

Just tested this with touch policy = never, i.e. a button press is never asked for the key in the given slot, still getting the same error.

This is apparently the token requiring the PIN code to be submitted for every privileged operation. I see some possibilities here:

• relogin on CKR_USER_NOT_LOGGED_IN and retry the operation once more
• relogin just before C_Sign

As for buying one, I'd suggest to perhaps wait for a newer version to be released, since FIDO2 standard has been finalised recently, and Yubico has yet updated only their cheapest model (Security Key), which supports U2F and FIDO2 only.

[jsfrederick]

@chris2511 , if you need some Yubikey's, I can send you some. Contact me privately with a mailing address.

[chris2511]

Hi jsfrederick, thanks for the offer. I'm very interested, please contact me at [email protected]

[Staja]

Any updates on this issue?

Update: For anyone else stuck on this issue, I got XCA working with a Yubikey 4 by changing the slot holding the keypair in question to have a pin-policy of once and touch-policy of always using the yubico-piv-tool by reimporting a PKCS12 package.

[hajikhorasani]

@Staja I'll be really appreciated if use CryptokiMPX to generate some logs in some successful scenarios with Yubikey 4, and send them to me: https://github.com/hajikhorasani/cryptokimpx

[ya-isakov]

I has the same issue, and I've found that this relates to issues in OpenSC https://github.com/OpenSC/OpenSC/issues/1545, https://github.com/OpenSC/OpenSC/issues/1269. So, the solution would be to check if the key on token is CKA_ALWAYS_AUTHENTICATE, and do C_Login(CKU_CONTEXT_SPECIFIC,...) P.S. Working solution could be seen in https://github.com/letsencrypt/pkcs11key/pull/24

[gentoo90]

Hi. Having the same issue here. As a workaround, signing works if you use opensc-pkcs11.so as a provider and ignore user consent on PIN caching in /etc/opensc.conf:

app default {
	# debug = 3;
	# debug_file = opensc-debug.txt;
	framework pkcs15 {
		# use_file_caching = public;
                # vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
		pin_cache_ignore_user_consent = true; # <=== ADD THIS
                # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	}
}