Issue with EC key length

[Chris]

Hi,

I'm trying to get JSignPdf to work with a Smart Card from Telesec and I can't figure out why it's not working.

When I try to sign a PDF, I get this error:

FINE KeyStore type JSIGNPKCS11 is supported by the provider JSignPKCS11-Telesec
SEVERE Problem occured
java.security.InvalidKeyException: EC key must be at most 201 bits
    at com.github.kwart.jsign.pkcs11.P11Signature.checkKeySize(P11Signature.java:407)
    at com.github.kwart.jsign.pkcs11.P11Signature.engineInitSign(P11Signature.java:473)
    at java.security.Signature$Delegate.engineInitSign(Signature.java:1329)
    at java.security.Signature.initSign(Signature.java:621)
    at com.lowagie.text.pdf.PdfPKCS7.<init>(PdfPKCS7.java:638)
    at net.sf.jsignpdf.SignerLogic.signFile(SignerLogic.java:364)
    at net.sf.jsignpdf.SignerLogic.run(SignerLogic.java:118)
    at java.lang.Thread.run(Thread.java:748)

INFO Finished: Creating of signature failed.

It seems to use a length of 256 when the certificate only supports 201. When I run JSignPDF with a java debugger and manually change the value of keyLength to 201 in com/github/kwart/jsign/pkcs11/P11KeyStore.java:1403 at runtime, a valid signature is added to the PDF, so everything seems to be working, except for the wrong key length. Of course, always using the debugger isn't exactly practical, though...

I don't understand how keyLength = params.getCurve().getField().getFieldSize(); actually gets the value and why it might get a wrong value; I also don't understand yet if this might be an issue with jsign.pkcs11, with the java crypto itself or with the PCKS#11 library I use (libpkcs11tcos3SigG_x86_x64-1.8.0.dylib
from Telesec: https://www.telesec.de/assets/downloads/Secure_Elements-Smartcards/PKCS11-SDK/PKCS11_MAC.zip).

I'd be grateful for any hints as to what might cause or what might solve this.

Chris

[Josef Cacek]

Hi Chris,

could you check by the debugger in the P11Signature constructor what
the value of algorithm (String) and mechanism (long) parameters is?
The value 201 for maximal key length seems to come from a native call
to your PKCS#11 library - C_GetMechanismInfo(...).
If needed, I could think about a workaround: e.g. a system property
that when used would disable the mechanism checks for ulMinKeySize and
ulMaxKeySize.
-- Josef

čt 21. 7. 2022 v 21:56 odesílatel Chris <therofl...@gmail.com> napsal:

> --
> You received this message because you are subscribed to the Google Groups "JSignPdf" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jsignpdf+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jsignpdf/89f6ecaa-7e3a-4c08-9a4f-7640e87fed1bn%40googlegroups.com.

[Chris]

Hi Josef,

thanks for the quick reaction! The constructor is called with SHA256withECDSA and 4161 when I use SHA256, SHA1withECDSA and 4162 when use SHA1.

The token seems to have both min and max keyLength set to 201 for all mechanisms (excerpt from OpenSC's Mechanism Info):

  SHA-1, keySize={201,201}, digest
  SHA256, keySize={201,201}, digest
  SHA384, keySize={201,201}, digest
  SHA512, keySize={201,201}, digest
  RIPEMD160, keySize={201,201}, digest
  ECDSA, keySize={201,201}, hw, sign, verify, EC F_P, EC OID, EC uncompressed
  ECDSA-SHA1, keySize={201,201}, hw, sign, verify, EC F_P, EC OID, EC uncompressed
  ECDH1-DERIVE, keySize={201,201}, hw, sign, verify, EC F_P, EC OID, EC uncompressed

A workaround would be awesome, but I'm not sure that disabling the checks would work: I can add a valid signature if I change the key length to 201 in P11KeyStore.java:1403 (at runtime), but when I just change the maxKeyLength (again at runtime) for the check to pass, I get another error:

java.security.ProviderException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_SESSION_HANDLE_INVALID
    at com.github.kwart.jsign.pkcs11.P11Signature.engineSign(P11Signature.java:662)
    at java.security.Signature$Delegate.engineSign(Signature.java:1382)
    at java.security.Signature.sign(Signature.java:698)
    at com.lowagie.text.pdf.PdfPKCS7.getEncodedPKCS7(PdfPKCS7.java:1261)
    at net.sf.jsignpdf.SignerLogic.signFile(SignerLogic.java:425)

    at net.sf.jsignpdf.SignerLogic.run(SignerLogic.java:118)
    at java.lang.Thread.run(Thread.java:748)

Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_SESSION_HANDLE_INVALID
    at sun.security.pkcs11.wrapper.PKCS11.C_SignFinal(Native Method)
    at com.github.kwart.jsign.pkcs11.P11Signature.engineSign(P11Signature.java:616)
    ... 6 more

Is there a way to somehow provide a "custom" key length? I don't understand yet where the 256 in P11KeyStore.java:1403 comes from, but it seems like if there was a way to change that, it'd work.

Again, thanks for your time, Josef!

Chris

[Josef Cacek]

Hi Chris,
I prepared a small workaround in the following PR. Could you check\,
if it solves the problem?
https://github.com/intoolswetrust/jsign-pkcs11/pull/12

Regards,
-- Josef

po 25. 7. 2022 v 14:43 odesílatel Chris <therofl...@gmail.com> napsal:

> To view this discussion on the web visit https://groups.google.com/d/msgid/jsignpdf/cbbc7a78-9425-4ec5-84b2-cc9423e8d60fn%40googlegroups.com.

[Chris]

Hi,

I think I might have sent my response privately by accident. So once more: The workaround does solve the problem.

However, I did some further testing and found out that the results regarding the validity of the signature varied depending on the validation tool I use. I'm trying to produce a QES and I now understand that JSignPDF is somewhat limited by its dependencies in this regard, but some validators mentioned issues with the signature itself, without going into too much detail. So I'm now not sure anymore that the workaround actually produces valid signatures.

I'm sceptical it makes sense to merge this without a better understanding of where the wrong key length came from, which I still haven't been able to figure out.

Because of the limitations of the PDF dependencies, I think I'll unfortunately have to look for an alternative solution for my use case even if the key length problem goes away, so as long as I'm the only one with the problem, I think it's probably safer not to merge it.

Still, thank you very much for the effort, Josef!

Chris

[Josef Cacek]

Hi Chris,
thanks for sharing your findings.
If you evaluate more solutions and find some working ones for your
case, it would be great if you could share your findings here too.
Regards,
-- Josef


po 15. 8. 2022 v 12:26 odesílatel Chris <therofl...@gmail.com> napsal:

> To view this discussion on the web visit https://groups.google.com/d/msgid/jsignpdf/17257318-a0b1-4569-8c72-4033039df710n%40googlegroups.com.