PKCS#11 CKM_RSA_PKCS Sign

[robert.simion]

Hello guys,

I am developing a pkcs#11 library especially to sign a document using the CSC protocol. I loaded this library in Adobe as a PKCS#11 module.

I need Adobe to sign only THE hash, because the CSC protocol requires this, but, when signing, adobe calls C_SignInit with the sign mechanism set to CKM_RSA_PKCS, which is a PADDED hash. It does this despite that the library does not support this signing mechanism. (which btw, this info is send with C_GetMechanismList, which lists all the mechanisms available in the library).

The problem is that Adobe does not call C_GetMechanismList, nor C_GetMechanismInfo to verify the mechanisms supported by the library. Even if CKR_MECHANISM_INVALID is returned by C_SignInit when CKM_RSA_PKCS is specified, Adobe again try to call C_SignInit and then the process fails.

Is there a way to tell adobe to change the mechanism to another, let's say CKM_RSA_X_509? Or maybe to make it verify the mechanisms available?

I am using Adobe Acrobat Reader DC v19.012.20035

Thank you,

Robert

[margueritek]

I don't see the problem. You don't send a padded hash to C_sign, you just send the bytes to be hashed. What you do with them is up to you. Acrobat (currently) knows only PKCS #1 v1.5 RSA as the RSA signing mechanism. There is talk to add PSS and/or OAEP in PDF version 2.0 or later. The hash is signed, then the signed hash is padded to the RSA length. Since it is the PKCS#11 module that signs the hash and adds the padding, you could do what you want with the signature.

[margueritek]

Of course, you will run into the small problem that Acrobat doesn't know how to validate RSA signatures signed with other than PKCS#1 v.1.5. How did you plan to address that?

[robert.simion]

The problem is that, on verification, adobe expects that the signature is made for the padded hash (51bytes) it had sent to the pkcs#11 module. The CSC protocol requires that signatures are made on the hash only (32 ot 64 bytes).

Of course I could unwrap the hash sent and then sign it with CSC protocol but then Adobe would not know how to validate this signature because the decrypted signature with the public key would not match with the paddedhash provided by the Adobe. (Adobe does it s own verification and does not call c_Verify).

[margueritek]

That is correct. Acrobat only uses PKCS#11 for signing. You would need to replace the entire signature handler with a custom handler, and all your clients would need copies of that custom handler for verification. If you are using any CA that is rooted in the Acrobat Trust List, you also need to deal with the fact that they will all be signing CRLs and OCSPs with PKCS#1 and not CSC. So, as a matter of interest, who is requiring CSC? Or is this just an acedemic exercise? And why does it matter?

[robert.simion]

The project is about signing documents in the cloud by the means of a pkcs#11 module. It does matter because, in order to sign a doc online, you would not need to modify the existing applications that use pkcs11.

So, the only way is to create a custom signature and/or verification handler for the Adobe to do what is required? I thought Adobe would firstly check what mechanisms were available on the token and then use them accordingly. Lets say, if  CKM_RSA_PKCS is not available, it  would try another mechanism for signing, and it will keep

this in mind at the verification level.

[margueritek]

A couple of things to keep in mind: The PDF standard does not define any RSA options other than PKCS#1, and that dates back to Acrobat 6, which was released in 2003. For interoperability and backwards compatibility (older viewers) it is not desireable to use features that are/were not available in earlier versions of Acrobat, unless there is a compelling reason to do so.

Cloud Signing is (or will be) supported using protocols developed by the Cloud Signature Consortium. Please see: https://cloudsignatureconsortium.org/

Cloud Signature Consortium . A PKCS#11 module that interfaces to the Cloud Signature standard would be great for earlier versions of Acrobat.

[robert.simion]

It would be great but it can't be done for adobe because it doesnt support signature of hashes (only hashes), which is a requirement of the CSC protocol.

[margueritek]

Once again, my question is why do you need CSC protocol? Any PDF signed with that protocol will be unverifiable in Acrobat, at least.

[robert.simion]

If it were verifiable (but it isn't because of the reasons talked above), it would leverage the clients, who use a physical token, not to require it anymore. It reduces costs on all levels.

[margueritek]

I've never seen a physical token that signed with RSA, that didn't support PKCS#1. If you have a signed hash from the token, you can pad it using PKCS#1 v,1.5 for the signature in the document.

[robert.simion]

Okay, maybe I wasn't very clearly. The process is this. When you sign with adobe, it calculates the hash of the doc, 32 bytes for instance. Then, adobe pad the hash using pkcs#1 scheme, rezulting 51 bytes. Then, Adobe sends the padded hash to the token to sign it. After this, adobe appends the signature resulted to the document. On the verification step, Adobe decrypts the signature with the public key and it compares the result with the padded hash it calculates again.

The problem with this scheme talked above, CKM_RSA_PKCS, is that it signs the padded hash but the csc protocol requires only the hash to sign. It's a CSC requirement. Of course you could sign the doc, but the problem is at the verification step. Note that the dll module talks with abobe using pkcs11, but on the inside, it signs the hash using the csc protocol.

My very first question was this: is there any way to tell adobe to change the signing mechanism ckm_rsa_pkcs? It only knows this? Why doens t it verify first what mechanisms are available on the token? Because there is a mechanism which implies a scheme for signing only the hash, not the padded one. Its called CKM_RSA_X_509

What do are you reffering to when you say 'you can pad it using PKCS#1 v,1.5 for the signature in the document'?

[margueritek]

If you are not sending the entire document for hashing (which is not usually efficient for a token), you need to send either the hash (using CKM_RSA_PKCS) or the padded hash (using CKM_RSA_X_509). In the latter case, you generate the hash and pad it to the modulus length using PKCS#1, then call CKM_RSA_X_509 which just does the final encryption.

[robert.simion]

Firstly, Adobe does the processes described by you. I can't change them. Secondly, the CKM_RSA_PKCS and CKM_RSA_X_509  mechanisms are, by themselves , schemes in which you pad or not the hash and send them to the token to sign. You cant send a padded hash with the CKM_RSA_X_509 as parameter because it isnt the scheme used in the signing process. I mean the token only does the signing of whatever you send to it, despite the mechanism type. The adobe actually pad the hash. I checked this practically. However i stiil dont know the purpose of specifying the mechanisms on the c_Sign. Do you?

[margueritek]

CKM_RSA_X_509 encrypts (signs) the payload. If you send it a padded hash, then the result is the same as CKM_RSA_PKCS without the padding (provided you did the PKCS#1 pad correctly). You then take the result of the encrypt and format it properly as an RSA signature. That's why there is your PKCS#11 module sitting between Acrobat and the token. Just a bit of coding required. Take the hash given to you by Acrobat, pad it, encrypt, format the output as a PKCS#1 signature. If c_sign gives you the document bytes, you do the hash yourself before padding and encrypting. You aren't the first PKCS#11 implementation for Acrobat.

[robert.simion]

Yes you are right in the first part. However, Adobe sends to C_Sign the padded hash (51 bytes actually), and expects that the signature is done on the padded hash. I cant do the signature on the padded hash because of the requirements of the CSC protocol. This is the CKM_RSA_PKCS scheme

What i want to achieve is to make adobe send only the hash and to expect the signature be done on the hash only. This would be CKM_RSA_x_509.

Am i missing something?

[margueritek]

What you are missing is that Acrobat is not going to change. You can do any required rewriting in your PKCS#11 module. If Acrobat asks for RSA_PKCS it will send you a hash (not a padded hash, since the padding length is determined by the RSA key size). Even if it did send you a padded hash, you could just remove the padding to get the hash itself. What you need to do, then, is perform the PKCS padding and send a padded hash to the token with an RSA_X_509 method. Then what you get back is just the same as if the token could handle RSA_PKCS directly. Much of this information is available via Google. Many token providers have made this work. There are folks who read this forum who could write the PKCS#11 module for you. For a fee, of course.

[robert.simion]

That's the thing. With CKM RSA PKCS, Adobe sends a digest info of algid and the hash (the hash as you say) and expects that the result is the signature of the padded hash! This is the problem: adobe expects a signature of the padded hash! This is very important. The thing is I can't do the signature of the padded hash because the size of it doesn't match the requirements of the csc signature. The csc was thought to sign some hash, not a bigger, padded hash.

These said, I can't sign using ckm_rsa_pkcs. And we are back to the very first question. Does Adobe have a mechanism that verifies the signature (inside adobe) so that the result of the decrypted signature is the hash it provided to the token?

And also, thank you very much for these replies!

[margueritek]

CKM_RSA_X_509 will sign/encrypt anything up to the length of the RSA modulus. It is not restricted to the length of the hash.

[robert.simion]

Yes, that's right. Thats why i want adobe to use it and also to send for signing only the hash.

[margueritek]

Isn't going to happen.

[robert.simion]

Thank you, margueritek for your responses!

[margueritek]

Last reply: You have all the tools you need to write a PKCS#11 module for Acrobat. You just need to understand the interfaces between Acrobat and PKCS#11, and the PKCS#11 module and the token. All the algorithms you need are there, but some coding is required. If you can't figure it out yourself, you will need to call in a consultant to help.

[manas_ag]

Hi Robert, 

Hope you were able to solve your problem. I am trying to make a pkcs11 library that our team has developed, work with Adobe Acrobat for digital signing. However we are not able to find any developer guide or resources from Adobe for this. Adobe Acrobat is unable to load our current pkcs11 library without a meaningful error. From your discussions, it seems that you were able to get a deeper insight on how Adobe is interacting with your pkcs11 library. It would be very helpful, if you could point us in the right direction.

Thanks, 

Manas