Opensc: Signing fails in OpenSC 0.16 with: PKCS11 function C_SignFinal failed: rv = CKR_GENERAL_ERROR (0x5)

[gdsotirov]

I have a problem with OpenSC 0.16 in Slackware 14.2 (I use my own package). This makes my OmniKey CardMan 6121 and online banking unusable. There is no such problem with OpenSC 0.15 on the same OS. For the online banking I use Firefox, but to demonstrate the problem I used opensc-pkcs11 command line program. The same problem for Debian is reported in bug 826165.

Expected behavior

Signing with opensc-pkcs11 should work fine like in 0.15.

Actual behavior

Signing with opensc-pkcs11 with error CKR_GENERAL_ERROR like this:

$ pkcs11-tool --module /usr/lib64/onepin-opensc-pkcs11.so -t -l
Using slot 0 with a present token (0x0)
Logging in to "InfoNotary (PIN)".
Please enter User PIN:
C_SeedRandom() and C_GenerateRandom():
   seeding (C_SeedRandom) not supported
   seems to be OK
Digests:
   all 4 digest functions seem to work
   MD5: OK
   SHA-1: OK
   RIPEMD160: OK
Signatures (currently only RSA signatures)
   testing key 0 (99D807BB-9D5A-4345-8D18-8B831BB5D178)
error: PKCS11 function C_SignFinal failed: rv = CKR_GENERAL_ERROR (0x5)

I tried the suggestion to use pkcs15-init --finalize from issue #693, but I got this:

$ pkcs15-init --finalize
Using reader with a card: OMNIKEY CardMan (076B:6622) 6121 00 00
Failed to finalizing card: Not supported

Steps to reproduce

1. Upgrade to OpenSC 0.16;
2. Run pkcs11-tool --module /usr/lib64/onepin-opensc-pkcs11.so -t -l on the command line (or try to access online banking site with Firefox);
3. Enter PIN code.

As a workaround I downgraded to OpenSC 0.15, but I hope this problem could be resolved. Please, let me know if any other information is necessary.

[dengert]

https://pcsclite.alioth.debian.org/ccid/shouldwork.html#0x076B0x6622
reports reader does not support Extended APDU

I believe this is fixed by: commit: https://github.com/OpenSC/OpenSC/commit/e95b5151631f71fcee60a24d8d9d79f1c9719d8c

https://github.com/OpenSC/OpenSC/issues/735
I believe this was the first commit added after OpenSC-0.16.0 was released. @viktorTarasov ?

[gdsotirov]

@dengert, I guess you meant 0.16.0-rc1, which was released on 2016-03-22, because commit e95b515 was made on 2016-04-19. However, OpenSC 0.16.0 final was released on 2016-06-03 and as far as I could check the changes are into release's tarball, which I used to built my Slackware package.

[dengert]

I think you are right.

Do you have any other reader especially if you want to use RSA 2048? The reader still looks like a problem, because it does not support extended APDUs.

Did you update the opensc.conf file with the 0.16.0 version?

[gdsotirov]

No, I do not have other readers.

Did you update the opensc.conf file with the 0.16.0 version?

What you mean exactly? I frankly do not remember ever touching anything in the configuration file.

[frankmorgner]

If your reader doesn't announce extended length support via PC SC, you need to explicitly enable this in opensc.conf since 0.16.0.

[gdsotirov]

@frankmorgner OK, but how? Do you have any documentation reference?

[frankmorgner]

# Limit command and response sizes. Some Readers don't propagate their
    # transceive capabilities correctly. max_send_size and max_recv_size
    # allow setting the limits manually, for example to enable extended
    # length capabilities.
    # Default: max_send_size = 255, max_recv_size = 256;
    # max_send_size = 65535;
    # max_recv_size = 65536;

[gdsotirov]

You're right @frankmorgner - this is the problem. First, I tried the old default (i.e. 255/256), but then switched to 511/512:

$ cat /etc/opensc.conf | grep -E 'max_(send|recv)_size'
                # Default: max_send_size = 255, max_recv_size = 256;
                max_send_size = 511;
                max_recv_size = 512;
                # max_send_size = 255;
                # max_recv_size = 256;

and signing now works just fine as before:

$ pkcs11-tool --module /usr/lib64/onepin-opensc-pkcs11.so -t -l
Using slot 0 with a present token (0x0)
Logging in to "InfoNotary (PIN)".
Please enter User PIN: 
C_SeedRandom() and C_GenerateRandom():
  seeding (C_SeedRandom) not supported
  seems to be OK
Digests:
  all 4 digest functions seem to work
  MD5: OK
  SHA-1: OK
  RIPEMD160: OK
Signatures (currently only RSA signatures)
  testing key 0 (99D807BB-9D5A-4345-8D18-8B831BB5D178) 
  all 4 signature functions seem to work
  testing signature mechanisms:
    RSA-X-509: OK
    RSA-PKCS: OK
    SHA1-RSA-PKCS: OK
    MD5-RSA-PKCS: OK
    RIPEMD160-RSA-PKCS: OK
    SHA256-RSA-PKCS: OK
  testing key 1 (2048 bits, label=1579302C-58DD-45D4-BAE5-D4A5C3CA46E5) with 1 signature mechanism
    MD5-RSA-PKCS: OK
  testing key 2 (2048 bits, label=02F3CADD-12BC-439A-8CCF-CB1FF41DCD68) with 1 signature mechanism
    MD5-RSA-PKCS: OK
  testing key 3 (2048 bits, label=F25A042D-E48E-4109-AE95-DD5CF723C971) with 1 signature mechanism
    MD5-RSA-PKCS: OK
  testing key 4 (2048 bits, label=A27FA435-D6F7-4488-8DF0-4F4383C370EE) with 1 signature mechanism
    MD5-RSA-PKCS: OK
Verify (currently only for RSA):
  testing key 0 (99D807BB-9D5A-4345-8D18-8B831BB5D178)
    RSA-X-509: OK
    RSA-PKCS: OK
    SHA1-RSA-PKCS: OK
    MD5-RSA-PKCS: OK
    RIPEMD160-RSA-PKCS: OK
  testing key 1 (1579302C-58DD-45D4-BAE5-D4A5C3CA46E5) with 1 mechanism
    RSA-X-509: OK
  testing key 2 (02F3CADD-12BC-439A-8CCF-CB1FF41DCD68) with 1 mechanism
    RSA-X-509: OK
  testing key 3 (F25A042D-E48E-4109-AE95-DD5CF723C971) with 1 mechanism
    RSA-X-509: OK
  testing key 4 (A27FA435-D6F7-4488-8DF0-4F4383C370EE) with 1 mechanism
    RSA-X-509: OK
Unwrap: not implemented
Decryption (RSA)
  testing key 0 (99D807BB-9D5A-4345-8D18-8B831BB5D178) 
    RSA-X-509: OK
    RSA-PKCS: OK
  testing key 1 (1579302C-58DD-45D4-BAE5-D4A5C3CA46E5) 
    RSA-X-509: OK
    RSA-PKCS: OK
  testing key 2 (02F3CADD-12BC-439A-8CCF-CB1FF41DCD68) 
    RSA-X-509: OK
    RSA-PKCS: OK
  testing key 3 (F25A042D-E48E-4109-AE95-DD5CF723C971) 
    RSA-X-509: OK
    RSA-PKCS: OK
  testing key 4 (A27FA435-D6F7-4488-8DF0-4F4383C370EE) 
    RSA-X-509: OK
    RSA-PKCS: OK
No errors

I presume I should close the issue now, but is there a way to set these parameters per device?

[frankmorgner]

No, it's currently not reader specific.

Note that starting with libccid 1.4.8 (22 June 2012) the driver supports dwMaxAPDUDataSize. Since your reader announces extended length capabilities, OpenSC should detect the higher transitive values automatically...

[LudovicRousseau]

@gdsotirov can you provide a pcscd log as described in http://pcsclite.alioth.debian.org/pcsclite.html#support ?
Just start pcscd and connect your OmniKey CardMan 6121 reader. No need to use OpenSC at this step.

[gdsotirov]

@frankmorgner OK. I asked, because my aim is to ship general purpose OpenSC packages for Slackware and not ones that work only for me. Anyway, for now I would just note the specific configuration for readers like mine, which is actually quite old (I use it for at least 8 years now). What's strange for me is that I had no problem with the old defaults in OpenSC 0.15.0, but with OpenSC 0.16.0 I had to set 511/512 as I wrote above.

@LudovicRousseau Yes, I can, but later today or tomorrow, as I do not have physical access to the PC currently.

[frankmorgner]

The old default was to not expect any limitation on the transceive size for readers. This gave problems with readers that only supported short length APDUs. The new default is to assume short length capabilities only, which may give problems with extended length readers (as in your case). Since we often don't get information about the reader's limitations, we assume what most readers are capable of: Short length APDUs. I hope that @LudovicRousseau can fix the propagation issue at least for the CCID readers.

[gdsotirov]

@frankmorgner OK, that's clear now about the sizes. However, @LudovicRousseau found out that I'm using the proprietary CCID driver and we continue the discussion over LudovicRousseau/CCID/issues/27. I'll write back when we have some result, so this issue could be closed until then.

[PotcFdk]

This still happens with my device. Changing max_{send,recv}_size to to 511/512 fixes my issues.
What is the current state / which project's fault is this?

[frankmorgner]

I've implemented a workaround for CardOS that ignores the reader's limitation. If that's your type of card, then this issue will go away with the next release.