Unable to import pfx in YubiKey PIV manager

[kategray]

I am unable to import a .pfx file using the latest released .cap and the YubiKey PIV Manager GUI.

The card is successfully detected, and I am prompted to perform device initialization. I select to use the PIN as management key. Once that finishes, I go to Certificates, Authentication, and attempt to import a .pfx file.

This gets me the error:

"Error: Failed to load PKCS12 from file. Unable to import private key"

As a test, I generated a new .pfx from scratch using the following commands:

openssl req -new -keyout cert.key -nodes -outform PEM > cert.csr
openssl x509 -in cert.csr -out cert.pem -req -signkey key.pem -days 1001
openssl pkcs12 -export -out cert.pfx -inkey cert.key -in cert.pem -password pass:test

Import still fails.

[kategray]

Additionally, if I re-open the management app, and attempt to load, it will prompt for the PIN and then the Management key.

I'm wondering if the key derivation for the management key is failing some how.

[kategray]

It looks like it may have something to do with the management pin. Manager is just calling the piv-tool, with the command:

C:\PROGRA~2\Yubico\YUBIKE~1\yubico-piv-tool.exe  -r "ACS ACR33U-A1 3SAM ICC Reader ICC 0" -s 9a -K PKCS12 -a import-key --touch-policy never -k --stdin-input

[arekinath]

It seems that the GUI manager app tries to write a special configuration object into the applet (with tag 5FFF00, in the same proprietary prefix that Yubico put the attestation cert). When it fails to write it, a bunch of the bits related to mgmt key derivation in the GUI app start to produce incorrect results, which is unfortunate.

I've reproduced this myself, and then also altered the applet to support storing and retrieving this configuration object at 5FFF00 and it seems to work properly after that.

It looks like the newer ykman (and its GUI app) also uses this same slot, so it'll help there too (though it currently doesn't let you set the reader name and also expects a bunch of other applets to be running as well as PIV, unfortunately)

[kategray]

This fixed the error with it keeping popping up the PIN dialog, but it still won't let me import.

Using a fresh install of the latest .cap:

Attempt to import:

Test certificate, password "1234".

testcert.zip

[kategray]

Trying to hunt down what's going on here, I did a capture. The first packets (<=8722) were launching the YubiKey PIV manager, letting it detect the card, and changing the PIN/master key (to 222222 and a derived master key from the PIN). The later packets (>=12890) consist of attempting to load a P12 file to the card. It's a test .p12.

I've attached both a text and a pcap capture of the process.

capture.txt
capture.zip

[arekinath]

It looks like over and over again throughout this it's failing to perform the admin (9b) authentication with the card. Interestingly, this is not what it does for me here (it seems to work fully from setting up PIN to importing a p12 file) -- but I'm on Linux not Windows and might have a different version of the PIV manager. Is there any chance you could get a APDU trace like that with the full data rather than "..." at the end of things? It would be useful to see the full 3DES key it actually set the admin key to and try to verify the encryption by hand.

[kategray]

Looks like the pcap file is truncated by the windows usb capture driver I'm using. I'm working on a utility to reconstruct packets from the USB analyzer I have into WireShark so I can use the CCID decoder and dump all the APDUs.

[arekinath]

Ah, sorry, thought the pcap was truncated as well, but it isn't actually in any of the packets that actually matter (just in some mostly irrelevant spots).

Looking at the admin auth attempts, it seems like the card is behaving correctly. The value for the first challenge-response pair that the host is sending (with the default admin key) looks right, then it changes the admin key, and then the auth on the new admin key looks ok as well. In the final exchange of the earlier set of packets it writes the PIVMAN file, and that succeeds. This is roughly the same as what I observe pivman doing to my test cards if I just go through to the main screen after setting the PIN and don't try to import any certificates or generate any keys, so that makes sense.

In the second set of APDUs (after +83 seconds) the host does successful admin auth with the card and then... stops? It doesn't send any APDUs to try to import a key or certificate, but it also doesn't receive any errors from the card. I've decrypted the challenge-response pairs there and the admin auth looks fine and using the correct key (the new one it set in the first exchange). It seems like it's not actually trying to send the key/certificate to the card.

Could it be that it's actually having trouble interpreting the .p12 file itself? We might need to debug pivman rather than the card here.

FWIW I've tried with the .p12 you have in the testcert.zip above too on my machine and it seems to import fine. I also did a round-trip signature test afterwards and it seemed to work... so I'm a little mystified, sorry.

[arekinath]

To clarify, I don't mean that I think it's not the applet's fault (since you said it works with a real yubikey), but I'm not sure we're going to figure out what it's doing wrong from its side or the packet trace (since the application has decided not to bother trying the key import apparently)