PKCS#11 AES CBC decryption triggers CKR_OPERATION_ACTIVE in continuous session

[bgermann]

Using the PKCS#11 subsystem with SoftHSM2 and tpm2-pkcs11 modules, I end up with CKR_OPERATION_ACTIVE in the following scenario:

wc_Pkcs11Token_Init(t, ...)
wc_Pkcs11Token_Open(t, ...)
wc_CryptoCb_RegisterDevice(..., wc_Pkcs11_CryptoDevCb, t)
wc_AesInit_Id()
...
wc_AesSetIV()
wc_AesCbcDecrypt()
wc_AesSetIV()
wc_AesCbcDecrypt()

The CKR_OPERATION_ACTIVE triggers in the second wc_AesCbcDecrypt() call. The problem is that the decryption context can still be around in the PKCS#11 session when Pkcs11FindKeyByTemplate() runs C_FindInit(). A possible solution would be to introduce a call to C_DecryptFinal() in wc_AesCbcDecrypt(). As there is no padding involved, this should be fine.

I have only verified this issue with wc_AesCbcDecrypt operation but I guess it is also applicable to at least wc_AesCbcEncrypt. The GCM mode should not be affected as C_DecryptFinal() is called there already.

Please note that this applies only with wc_Pkcs11Token_Open in place. Else, every PKCS#11 operation runs in its own session, which is a big overhead.

[SparkiDev]

Hi @bgermann,

I've put up a pull request that makes a PKCS11 call to C_Decrypt rather than C_DecryptUpdate.
#4146

The encrypt operation was already using C_Encrypt.
I don't remember why the difference in API usage and I may have to put in ifdefs to enable the old behaviour.

Let me know if this works for you.

Thanks,
Sean

[bgermann]

Yes, this works as well.

[SparkiDev]

Hi @bgermann,

Do you have any further problems with the AES-CBC code in PKCS#11?
If you are happy with this fix, I will close this ticket.

Thanks,
Sean :-)

[bgermann]

No, I am fine.