OpenPGP card: Decrypt

[msetina]

Using OpenPGP card it lists RSA_PKCS with decrypt flag. I am trying to find if this is not correct as I do not see RSA decryption in OpenPGP standard.
If it is correct, what mecahnism can it use?

[dengert]

It is called : "7.2.11 PSO: DECIPHER...........................................................................................67" in OpenPGP Smart Card Application V3.4.1

[dengert]

"7.2.18 MANAGE SECURITY ENVIRONMENT"

With OpenPGP to only supports 3 keys;
• Signature key (Key-Ref 1) binded to PSO:COMPUTE DIGITAL SIGNATURE
• Decryption key (Key-Ref 2) binded to PSO:DECIPHER
• Authentication key (Key-Ref 3) binded to INTERNAL AUTHENTICATE

So with older versions even though all three keys could by RSA only one can be to decipher. Later versions support the use of MSE that allows some dual usage.

[msetina]

Thank you. I missed it.
Am I correct, that the card will decrypt whatever padding is made?
The card supports only decrypt so I can not do the test implementation with full path, so I have to help myself with python cryptography to make the encrypted message.

[Jakuje]

I think the encryption is implemented in OpenSC so if you will call C_Encrypt(), it should do. The same for the different padding modes even if the card supports only raw operation.

[dengert]

Am I correct, that the card will decrypt whatever padding is made?

No. Most cards only implement a very limited set of any standard, and leave padding up to the calling middleware. Many will only do RSA RAW which is used to sign some data where the padding is done in software and sent to the card to do the RSA RAW. Decryption is done be sending the the card the encrypted blob. The card does RSA RAW and returns a blob. The driver software checks that the blob is valid, by checking the padding and removing it.

Each OpenSC card driver passed a set of flags when calling _sc_card_add_rsa_alg. which says what what the card can do (or the card driver can do withing the driver.) The upper layers the decied how to split up the work. So have a look at some drivers with name like card-<name>.c for the function <name>_init. and the flags: https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/opensc.h#L102-L218

The card supports only decrypt so I can not do the test implementation with full path, so I have to help myself with python cryptography to make the encrypted message.

That is out of scope for OpenSC.. OpenSC drivers and code or other software can do the public key operations to encrypt a message and verify signatures.

[msetina]

Thank you. You are very helpfull. I am fighting with python and I have not seen those flags in that form, but as flags on slot and am already using them to limit capabilities to those that card can do.
Since my goal is to connect python cryptography and this fine project, you have helped me to know now what to request from cryptography project. I hope there are accesible points to execute padding before( or after on decryption) calling the card. If I can also utilize digests on the card would be cool.

[dengert]

If you really want to connect to "this fine project" (thank you) I would suggest using PKCS11 which deals with all of your issues.

In one of you other discussion you were asking about EC curves and public keys. Have you looked at the PKCS11 v 3.0

CKA_PUBLIC_KEY_INFO
Byte array
DER-encoding of the SubjectPublicKeyInfo for this public key. (MAY be empty, DEFAULT derived from the underlying public key data)

This returns the EC curve OID and public key in the SPKI format as used in certificates. The CKA_EC_POINT returns just the ec point Q value.

Another options is to use OpenSSL and either https://github.com/OpenSC/libp11 or https://github.com/latchset/pkcs11-provider both of which allow OpenSSL to use PKCS11.

[msetina]

I have not used CKA_PUBLIC_KEY_INFO as I thought it was in the future. Will check it on EOI. I was able to combine CKA_EC_POINT and CKA_EC_PARAMS to get the public key for cryptography.

[dengert]

You are right, CKA_PUBLIC_KEY_INFO is part of https://github.com/dengert/OpenSC/tree/X25519-improvements-2
dengert@b8eb37b

I have been waiting till after 0.25.0 was release to submit the X25519-improvements-2 branch as a PR.

[Jakuje]

The 0.25.0 is out so I think its time to open the PR (reviewing branches without PR is hard).

[dengert]

CKM_RSA_PKCShas no padding, right?

No, CKM_RSA_PKCS is RSA using PKCS 1.5 padding.

RSA without padding is what I was calling RSA-RAW is CKM-RSA-X-509.

Since CKM_RSA_PKCS other padding mechanisms have been defined, CKM-RSA-PKCS-PSS and CKM-RSA-PKCS-OAEP.

pkcs11-tool -M will list all the mechanisms (without the leading CKM-) supported by the card or the module's software.