RFE: modernize PKCS#11 RSA mechanism to PKCS/PSS/OAEP

[space88man]

Version

5.7.2

Description

It is discouraged to call the raw RSA mechanims on a token CKM_RSA_X_509 which is used by wolfCrypt PKCS#11.
This mechanism is not supported by Thales LUNA.

The enhancement would be for wolfCrypt -> CryptoDev -> token to use modern mechamisms like RSA_PKCS/RSA_PKCS_PSS/RSA_PKCS_OAEP for signing and decryption.

My testing observations:

• wolfCrypt only uses CKM_RSA_X_509 (supported by softoken but not LUNA)
• OpenSSL openssl-pkcs11 or pkcs11-provider use RSA_PKCS or RSA_PKCS_PSS

[space88man]

I am interested in this feature but not sure how the wolfCrypt RSA operation splits work between software (padding/hashing(PKCS, PSS)) and CryptoDev(raw encryption/decryption). Any pointers to the source code would be very helpful.

[SparkiDev]

Hi @space88man,

While it would be nice to have the whole operation done on the device, it was cleaner for our code to have only the RSA operation done down there.

The wc_CryptoCb_Rsa() calls in rsa.c are where the PKCS#11 code is invoked.

Note that the RSA-PSS sign could be easily modified to call a new callback, the verify is broken into two parts which would take a bit more effort but again is not difficult. Similarly the OAEP encrypt/decrypt would require new callback but would be easy to implement.

Sean

Sean

[space88man]

While it would be nice to have the whole operation done on the device, it was cleaner for our code to have only the RSA operation done down there.

Yes - it's cleaner to only dispatch the raw RSA operation and keep the rest the same.

The glitch for me ATM is that LUNA disables CKM_RSA_X_509 in FIPS mode 😣. It supports raw RSA in non-FIPS mode

For TLS/signing use cases (PSS/PKCS) and ignoring OAEP:

/* pass the original input array downstream in case CryptoCb wants to do
  * its own padding */
int wc_RsaFunction(const byte* in, word32 inLen,
            byte* out, word32* outLen, 
             const byte* originalIn, word32 originalInLen,
              int type, RsaKey* key, WC_RNG* rng)

/* and this dispatches to */
static int wc_RsaFunction_ex(const byte* in, word32 inLen, byte* out, word32* outLen,
                              const byte* originalIn, word32 originalInLen,
                             int type, RsaKey* key, WC_RNG* rng,
                              int checkSmallCt)

// something similar needed for wc_CryptoCb_rsa
// cryptoInfo.pk.rsa needs to change to take the pre-padding array

IOW, "cache" the original array and pass it down the stack together with the library-padded array in case CryptoCb wants to handle padding on its own.

The semantics are: if originalIn == NULL it can be assumed there is no "original" array. If originalIn != NULL then in is a transformed(padded) version of originalIn.

The total number of callers to wc_RsaFunction(...) and wc_RsaFunction_ex(...) is manageable

As a start do you think this is acceptable?

[SparkiDev]

Hi @space88man,

My preference is to have new calls to wc_CryptoCb_Rsa higher up.
New types could be added: WC_PK_TYPE_RSA_PSS, WC_PK_TYPE_RSA_OAEP.
Then it could be handled in the callback which operation is wanted.
This risks existing callback implemenations failing but can be disables with a #ifdef.

Sean

[space88man]

My preference is to have new calls to wc_CryptoCb_Rsa higher up. New types could be added: WC_PK_TYPE_RSA_PSS, WC_PK_TYPE_RSA_OAEP. Then it could be handled in

Let me work out something for WC_PK_TYPE_RSA_PKCS/PSS.

[space88man]

WIP: test files both software RSA(to ensure nothing broke) and token RSA for upcoming PR for RSA PKCS-offload. NSS Softoken with RSA private key included.

Token PIN is: 12345678

testing-v2.zip