Problem interacting with OpenSC, maybe with p11-kit too #234
Comments
|
Maybe I am missing something, but I don't see an example of using /usr/local/lib/opensc-pkcs11.so directly. Does it fail when only " #pkcs11-module-path = /Library/OpenSC/lib/opensc-pkcs11.so" is uncommented? What modules is p11-kit loading? What version of OpenSC is it loading? |
You mean with
Oh yes.
p11-kit is loading OpenSC, YKCS11, SOftHSM, and YubiHSM2 drivers. |
|
One correction. with provider - YKCS11 also seems to fail on signature: |
|
Here's more details:
Finally, |
|
based on the spy2.log.txt: It appears OpenSC does not support If it did for private keys it would be in https://github.com/OpenSC/OpenSC/blob/master/src/pkcs11/framework-pkcs15.c#L3981-L4118 |
|
Maybe if and if found, assume the card can do it and try the crypto operation. |
|
It looks like provider fixed a similar problem for SoftHSM: 0e25049 |
|
@dengert pkcs11-provider already filter session by the mechanisms supported by the token. @mouse07410 not sure what I should do, I just tested once again the dgst sign/verify with the yubico pkcs11 driver and it works fine here. The cms also works fine with the yubico driver. What version of the provider are you using? To me it seem this may be either a bug/limitation in p11-kit proxy or in OpenSC, but the logs are not enough to figure out what fails. The CKA_ALLOW_MECHANISMS is not the problem if this is origin/main of pkcs11-provider, but it could be if you use OpenSC and older build. |
Frankly, I don't know - the problem stymies me, and I've no clue what seems to be causing it. The only thing that seems reasonably sure is that OpenSC does not integrate well... I use:
If you (or somebody else) could tell me how to get more/other logs that could be more helpful - I'll be happy to provide. |
|
I think we need to go in steps. You showed a failure with a Yubikey (4 or 5) in generating a PSS signature. |
|
I can reproduce one of @mouse07410 problems on Ubuntu 22.04 with OpenSC master, OpenSSL 3.1.0 and provider main with Yubico 5: I could be wrong, but it looks like in OpenSSL dgst.c calls EVP_DigestSignInit_ex at: But does not process the PSS sigopts until: https://github.com/openssl/openssl/blob/master/apps/dgst.c#L365-L375 Thus the provider does not have any of the PSS parameters during This would only effect the provider when doing RSA with parameters, such as PSS. I am going to try and move the code later today to see if that is a fix. |
This is normal, the provider does not do anything but retrieve the key at "digest_sign_init". The provider defers the pkcs#11 Sig Op initialization until the first "digest_sign_update" call is performed exactly to account for this OpenSSL behavior. |
|
The problem here is that it seems that there is no CKM_RSA_PKCS_PSS exposed as a valid mechanism by the token. Can you run pkcs11-provide with level:2 debug to figure out the list of mechanisms exposed by the slot the key is on? |
I am pretty sure Yubikeys (and other smartcards) can not do RSA-PSS on-board, and rely upon the supporting software/driver/etc to perform the PSS part. |
As far as I know the OpenSC driver deals with that, but I may be wrong. |
|
Here is something ... OpenSC built from master does not list any of these! |
|
Current (master) OpenSC and YKCS11: $ pkcs11-tool --module /Library/OpenSC/lib/opensc-pkcs11.so -M | grep PSS
Using slot 0 with a present token (0x0)
RSA-PKCS-PSS, keySize={1024,3072}, hw, sign, verify
SHA1-RSA-PKCS-PSS, keySize={1024,3072}, sign, verify
SHA224-RSA-PKCS-PSS, keySize={1024,3072}, sign, verify
SHA256-RSA-PKCS-PSS, keySize={1024,3072}, sign, verify
SHA384-RSA-PKCS-PSS, keySize={1024,3072}, sign, verify
SHA512-RSA-PKCS-PSS, keySize={1024,3072}, sign, verify
$ pkcs11-tool --module /usr/local/lib/libykcs11.dylib -M | grep PSS
Using slot 0 with a present token (0x0)
RSA-PKCS-PSS, keySize={1024,2048}, hw, sign, verify
SHA1-RSA-PKCS-PSS, keySize={1024,2048}, hw, sign, verify
SHA256-RSA-PKCS-PSS, keySize={1024,2048}, hw, sign, verify
SHA384-RSA-PKCS-PSS, keySize={1024,2048}, hw, sign, verify
SHA512-RSA-PKCS-PSS, keySize={1024,2048}, hw, sign, verify
$ I don't know whether the driver ( |
|
PIV cards only do CKM_RSA-X-509 on the card i.e. RSA RAW. The rest is done in OpenSC. Something has changes in OpenSC between 0.23.0 and master. OpenSC 0.23.0 pkcs11-tool works: and here is level:2 log: Starting git bisect... |
|
OpenSC Commit 1d5c81e85baaa82973e1080dfb34876830bee067 appears to be the problem. Committed March 29. Reverting it in OpenSC master causes test to work. The changes was for one specific card, but it looks like it causes problems with at least PSS and maybe other cards. @mouse07410 try |
Thank you! Reverting this commit did not fix p11-kit problem, but restored OpenSC to functioning correctly. First call to So, how do we fix this p11-kit problem? Having different tokens, it's very convenient to have a switch that automatically figures which module to load for a given key URI... @neverpanic could you pitch in please? UpdateI wonder how Some kind of weird interaction between |
|
I really do not see how interacting with PIN logins makes a difference ... @mouse07410 if you still have the problematic version available can you set pkcs11-module-login-behavior = always and see if that "fixes" the issue? |
First, I don't have the offending version anymore, sorry. But it doesn't seem to matter here. Regarding fixing - alas, no: Something between |
|
@dengert what is odd from your log is that there is clearly a signature operation going though ... and then a second attempt at initializing a signature operation with a null key .. I wonder if you reproduced the same error @mouse07410 has. |
|
@Jakuje I recall you told me that p11-kit-proxy may have had some limitation with some algorithms, can this be the case? |
|
@mouse07410 sounds to me like this is a p11-kit problem then. |
I see the logic - however, please note that when
I think not, because it works when engine is used instead of provider. |
The engine may be doing some emulation we do not want (yet) to do with pkcs11-provider. |
|
@mouse07410 can you trying this untested patch to OpenSC src/pkcs11/framework-pkcs15.c |
But in the last case the 2nd driver is for a different token altogether - it shouldn't even receive any calls. Why would it interfere? How does
I've applied the patch, but it did not seem to make a difference: prov-debug.txt And here's the successful trace from the screen-log-engine.txt Update
I've no idea. @neverpanic?
I don't think so. Everything's local from the |
Hmm I thought it was implied the two drivers were talking to the same hardware?
I do not think it does, I guess I misunderstood the problem.
It wouldn't be able to, the provider assumes it is talking to a single, coherent, driver. I think we are back to p11-kit not properly handling something pkcs11-provider does that libp11 engine doesn't. @dengert please do not return 0 length CKA_ALLOWED_MECHANISM values, although I currently have a workaround in because softhsm does that I plan to remove or put it behind a quirk, as a 0 length value really means: no mechanism supported for this key, go away. And yubico's driver plans to use it that way. If p11-kit really is choking on this value, I can add a configuration quirk (perhaps auto-detect it base on the token vendor/version even). @mouse07410 would you be willing to try a provider patch that prevents asking for CKA_ALLOWED_MECHANISMS entirely? |
Normally I have both But for the last tests, I put one module for Yubikey (the OpenSC one), and one for YubiHSM2. Completely different hardware.
;-) It's never been clear-cut for me.
Or the other way around?
Noted. I'll revert this patch.
Can't see how this could hurt - so let's do it anyway.
Of course! Just post the patch. |
|
Disagree with: "so it makes perfect sense that it would fail in retrospect." Smartcards are accessed by PC/SC, which provides a locking mechanism to lock access to the card for one or more transactions (ADPUs) There are Microsoft, Linux and MacOS implementations. https://pcscworkgroup.com/ This locking should prevent any other process or other PKCS11 modules from accessing the same card at the same time. The OpenSC PIV driver goes to great lengths to make sure the card login state has not changed in between transactions.
PKCS11 modules requests a list of readers when they start and check which reader have tokens and if they can support the token or tokens and read a lot of data form the token. So both drivers would be loaded andboth look at all the tokens. But only one would be used to do the sign operation based on the the URI selecting the driver I am not familiar with MacOS and how PC/SC is implemented, So it could be possible there are problems with locking. There should be only one system PC/SC daemon running. |
|
@mouse07410 When I built p11-kit I used: 233 configure: build options: |
Maybe "perfect sense" is an exaggeration, but if two drivers in the same process were to independently access pc/sc it may cause issues difficult to explain. Apparently this is not the case anyway so let's ignore this line of thought for now. |
|
@mouse07410 can you test the patch in #237 ? |
|
Requires setting this line in openssl.conf: |
|
Current main with #237 applied - still fails: Excerpt from Should I try to provide "full debug" output, as before? |
|
"Error setting context" appears 12 times in the issue, followed by "4083FE52F87F0000:error:03000096:digital envelope routines:do_sigver_init:operation not supported for this keytype:crypto/evp/m_sigver.c:298:" grep "Error setting" or grep "setting context" does not appear in any of packages involved accept OpenSSL in https://github.com/openssl/openssl/blob/master/apps/dgst.c#L354-L363 after the call to I built @mouse07410 you have the only test environment the has MacOS and 2 Yubikeys and some other PKCS11 modules. So getting a core dump or at least a stack trace would be very helpful. |
|
One other thing that could happen is is if two libs or modules have that same routine, and some how the loader/linker resolves an external reference to the wrong library. I saw this same type of problem with PAM and Kerberos module may years ago. |
I assume your
Core dump is next to impossible (unless the app actually crashes) - Macs are very comfortable to use, but darn inconvenient for debugging. Stack traces have also been problematic in the past. :-(
Hmm... This would be really unfortunate - as I'd expect every module to export pretty very similar (if not exactly the same!) API... Don't know what to say... To keep me (and you ;) fully entertained, here are results from OpenSSL-3.2.0-dev: Now - another trouble. Being quite annoyed by these apparently-useless assertions of the Macports-installed p11-kit I decided to try my luck on p11-kit master that I build from the source with Here's how I switched from Macports-installed p11-kit to this: I got a crash - with apparently Crash report: |
|
@mouse07410 can you run your tests using the Auth key( id=%01) rather then the Sign key (id=%02) This will eliminate the following problem in testing with p11-kit: The provider does not check private key for OpenSC in OpenSC was designed to work with PIN_PAD readers where the pin is never seen by the host computer and thus can never be cached thus requiring the user to prompted for PIN each time. Also check if you have ykcs11 also supports @simo5 May also be related to your: p11-glue/p11-kit#501 |
Same thing:
I'm pretty sure it does not apply here. Also, for OpenSC I have
If nothing is done to the token between Also, it looks like after completing the signature and upon closing , provider gets into infinite loop on I observe it with OpenSSL-3.2.0-dev (not with OpenSSL-3.1.0) and master p11-kit. |
|
Using OpenSSL-3.2.0-dev and building with Macports-installed clang-16: Crash report: |
Good to hear you are avoiding the problem. I test with |
|
The one other debugging tool we have not used is to run PCSCD (or what ever MacOS uses) in debug mode. Looks like provider or p11kit is sending C_Login to both cards found. (Has this been fixed?) The log on Ubuntu 22.04 with provider seams to show both OpenSC and ykcs11 are quering login state to both cards as expected. opensc-debig.log shows it was called to twice to login in to both readers: So something is wrong most likely provider it is calling C_Login for both cards it found. But It only sent one signature operation as seen in pcscd log: |
|
CPPFLAGS=-DDEBUG |
only space separated syntax is allowed |
|
OK, current state:
Without HSM module: With HSM module: Seg-fault above is infinite loop tha provider gets into on $ openssl version
OpenSSL 3.1.0 14 Mar 2023 (Library: OpenSSL 3.1.0 14 Mar 2023)
$ openssl3 version
OpenSSL 3.2.0-dev (Library: OpenSSL 3.2.0-dev )
$ |
|
Sounds like progress. Is this the HSM module you are using: https://github.com/Yubico/yubihsm-shell/blob/master/pkcs11/README.adoc It says is has debug options: What do they show? |
|
With all of those (debug, libdebug. dinout) turned on: At this point, signature was correctly computed and stored, openssl3 process crashed because of infinite loop in the pkcs11-provider. Crash report did not show up in With OpenSSL-3.1.0 - similar output from HSM debug trace, but signature failed: And, of course, removing HSM module, makes signature succeed: |
|
You might want to open an issue on https://github.com/Yubico/yubihsm-shell It looks like yubihsm_pkcs11.c is only called at the start and the failure appears to be when terminating and so logs are not flushed in the crash. I see |
When there is no crash but just failure to sign (OpenSSL-3.1.0) the logs also either not flushed or there's no more traffic to that device...
Yes. UpdateIt looks like when there's more than one argument to |
|
This one has run out of steam and seem multiple issues were mixed. |
Describe the bug
Fails to decrypt or sign. Showing example of CMS decrypt failure:
Excerpt from
openssl.cnf:To Reproduce
Steps to reproduce the behavior:
yubico-piv-toolif you have a Yubikey.openssl rand -base64 -out /tmp/pt.txt 30or so./tmp/pt.txtwithopenssl dgstor encrypt to YubikeyKEY MAN pubkeyviaopenssl cms.Expected behavior
Successful signature creation and verification, successful unwrapping of CMS.
Operating environment (please complete the following information):
Token and application used (please complete the following information):
Additional context
After replacing in
openssl.cnfpkcs11-module-path = /Library/OpenSC/lib/opensc-pkcs11.sowith/usr/local/lib/libykcs11.dylib:Another attempt, also successful:
With
openssl.cnfcontaining:With signature:
Using OpenSC
Using YKCS11
Foregoing p11-kit:
In
openssl.cnfforcing YKCS11:results in success
The text was updated successfully, but these errors were encountered: