libykcs11 breaks when ED25519 or X25519 key is present on the Yubikey #510
Comments
|
While the latest release does contain a bug related to handling of ED keys in YKCS11 (a patch release with a fix is scheduled soon), it should not effect RSA key functions. I am also unable to re-produce the issue using pkcs11-tool. Can you please set the environment variable |
|
|
I have now set up OpenSSL with PKCS11 engine. I generated RSA4096 keys on slot 9d, done both signing and decryption using the following commands: As expected, that worked fine. I then generated an ED25519 on slot 9c and repeated the same commands above with the RSA key in 9d. They still worked fine without any issues. I then repeated the same tests with an RSA4096 key imported into slot 9a both with slot 9c empty and occupied with an ED25519 key. Everything still worked as it should. So as of now, I am unable to re-produce the error you are getting. And I also don't see anything in the debug log you posted that jumps out as wrong. What YubiKey version do you have? How did you create the keys (I created them using the Do you have the possibility to build yubico-piv-tool from source? If yes, can you build it from the branch called |
I'm using the latest yubico-piv-tool release (2.6.0) and YubiKey 5C NFC with firmware 5.7.1.
I used ykman piv keys generate.
I don't have a compiler on the machine I'm using to test. I suspect OpenSSL enumerates all as part of locating the PKCS11 object and gets an error when it encounters the ED25519 key before the fix. Could you see if this bug reproduces on the release version (yubico-piv-tool 2.6.0)? Thanks, David |
|
Sorry I didn't make that clear but I am actually testing on the released version (reproduce first then see if the patch solves the issue :) ). I realized though that I'm testing with OpenSSL 1.1 but you are most likely running OpenSSL 3. Now I have finally gotten a configuration running with OpenSSL 3 and ran the same tests again, and I am still able to do both signing and decryption with both RSA and ED keys present on the same key. I don't have YubiKey 5.7.1 at hands at the moment but I tested with both 5.7.0 and 5.7.2 and I'm not encountering any issues. Can you try generating/importing the keys using the A patch release (yubico-piv-tool 2.6.1) should be coming out before the end of the week, so you can test that soon too. |
|
Thanks for looking, @aveenismail. I just tried using yubico-piv-tool to generate the keys, and the same problem repro'd for me - it can decrypt the RSA-encrypted file if and only if a previous slot does not contain an ED25519 key. Yes, I am using OpenSSL 3. Some other details, in case they're relevant: |
|
@aveenismail - I tried with the 2.6.1 release of yubico-piv-tool, and this bug still repros. I also tried putting the X25519/ED25519 key a later slot (9E), and that didn't change the behavior either. Note, however, that this problem does not reproduce with ECCP256 or ECCP384; it is specific to X25519 and ED25519. Have you been able to reproduce this problem with OpenSSL 3 and YubiKey 5.7.1? |
|
@davidmatson I am still unable to re-produce. I have, however, added some more debug output that can hopefully point us in the right direction. Are you able to download github artifact from https://github.com/Yubico/yubico-piv-tool/actions/runs/11128165948? You are running on Windows, correct? There should be an MSI installer there with binaries that produces more debug output. Can you run that with debug turned on and paste the output here? |
|
|
Thank you. To make sure, you have an RSA key in slot 9d and ED25519 key in slot 9a, correct? |
|
OK, I see that you have an RSA key in 9d and X25519 in 9a. YKCS11 reads all objects when it opens a PKCS11 session as expected. The weird thing is that it can clearly see that there is something in these slots because it does read the right key type, but it returns 0 as the length of the key. Can you paste an debug output where the X25519 keys is not there (aka, when it works) so we can compare? |
|
Yes, here's the config (ykman piv info): If I delete the key in 9A, here's the debug output: |
|
Thank you. OK, so it returns object length 0 even when everything works, so this is apparently not the issue. It looks like ykcs11 accurately reads the content of the key when it opens a PKCS11 session. Also ykman output lists the correct keys so it is not a hardware issue. Let me make new binaries with more debug log when searching for the key and get back to you. |
|
Suddenly, I am able to re-produce!! I did not do anything different!!! I see, however, that my OpenSSL version is upgraded from 3.0.2 to 3.0.13. Tested it again now and yes, everything works fine with OpenSSL 3.0.2 but breaks with 3.0.13. I see now in the comments above that you are running OpenSSL 3.3.1. I must have misread that because I was convinced you were running 3.0.1 and thought that one patch version cannot account for this. At least now I can dig properly on my end. Hopefully I'll be able to provide you with a binaries to test very soon |
|
That sounds great. Thanks, @aveenismail! |
|
Here is what I got so far: I am fairly sure that ykcs11 is behaving the way it's suppose to. When I have an EC key in 9a and RSA key in 9d, here's the debug output (I added more for clarity) from when it tries to find the RSA key: It continues to get more attribute values for this key, then fetchs the next key (in slot 9d) and proceeds to fetch its attribute values and so on. In the end, it matches the label to the one stated in the command line, picks the key with the right label and uses it to perform the private key operation. When I replace the EC key in 9a with an X25519, this becomes the debug output (which matches the debug output from your command): The only possible scenario for how this happens is that when OpenSSL gets the key_type value CKK_EC_MONTGOMERY, it considers that an error and interrupts the operation without trying to check the other keys it found. I started digging into the OpenSSL side of this to try and figure out what is happening. I still haven't managed to find the right piece of code but I do find it strange that the 25519 keys were supported in a previous version but not a later one, which leads me to think it could be a configuration issue. I checked the OpenSSL Changelog to see if this is mentioned and it wasn't, however, I found mention of a configuration option I have actually no reason to believe that support for the 25519 is turned off by default in your installation (or mine for that matter), but this is the most promissing lead I got to why later OpenSSL versions are behaving this way. I'll keep digging and hopefully figure this out, but this is how far I've gotten for now. |
|
Thanks, @aveenismail! I wonder if the problem is in libp11. From a quick skim of their code, I think they have RSA and ECC support but not ED255119/X25519: It looks like there's a related open issue: So maybe older versions of OpenSSL skipped unknown key types altogether, and when recent versions added support for this key type but libp11 didn't have them, that's when things started going wrong? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm using the latest yubico-piv-tool release (2.6.0) and YubiKey 5C NFC with firmware 5.7.1.
When using libykcs11.dll, it fails to be able to find any key on the YubiKey if any key, in any normal slot, exists using either the ED25519 or X25519 algorithms.
For example, using OpenSSL:
This command works just fine when only a single RSA4096 key exists in the appropriate slot.
But if I then generate a new key using ED25519 or X25519 in a different slot, the command above starts failing with:
If I delete the new ED25519 or X25519 key in the other slot, the exact same command starts working again.
The text was updated successfully, but these errors were encountered: