PKCS11/SoftHSM/RSA issue: Decryption with a different key to the one used for Encryption is allowed

[tgonzalezorlandoarm]

When trying to update the docker image parsec-service-test-all, the asym_encrypt_decrypt_rsa_pkcs_different_keys test fails for the PKCS11 provider.

This (negative) test encrypts a message with an RSA key and tries to decrypt it with another RSA key.
The RSA padding should allow the PKCS11 provider to realize that an incorrect key is being used and fail accordingly. The latter should happen when calling decrypt for the PKCS11 session.

SoftHSMv2 is being used as the software backend for the PKCS11 provider. A similar issue has been reported in there, for RHEL9. We are using Ubuntu 22.04.

Unfortunately, development in SoftHSMv2 is currently dormant (since last month) so it does not seem likely that we'll get a solution from that end.

[tgonzalezorlandoarm]

@gowthamsk-arm @ionut-arm what are your ideas on this?

I guess the best option would be to find a new testing module for the PKCS11 provider, but we could ignore this particular test for the pkcs11 provider in the meantime?

[ionut-arm]

Sounds like a good plan! Maybe there's some alternative PKCS11 implementation that you can use if this doesn't get fixed in SoftHSM...

[anta5010]

Do I understand correctly that the same version of SoftHSM behaves differently on different versions of OSes? That's strange. Is it know what causes that?
We use a specific SHA for SoftHSM in E2E tests. Have you tried the latest version?
Is the issue reproducible with the latest Yocto release?

Please remember that SoftHSM is also used in OE QA tests in meta-parsec. If you decide to use a different PKCS11 implementation then you will need to update the tests as well.

[tgonzalezorlandoarm]

Hi @anta5010 , thanks for the comment! We'll check with the new latest version and come back here

[tgonzalezorlandoarm]

@anta5010 latest version of SoftHSM fails as well

[tgonzalezorlandoarm]

@anta5010 Correct, if/when we change the implementation that we use, we'll need to update the OE QA tests in meta-parsec, thanks for the comment.

[tgonzalezorlandoarm]

Given the nature of the problem (a fixed SHA is failing when updating the docker image), we believe that this is due to the updates/changes in the toolchain, so it's not necessary linked to a change in OS.

[anta5010]

Given the nature of the problem (a fixed SHA is failing when updating the docker image), we believe that this is due to the updates/changes in the toolchain, so it's not necessary linked to a change in OS.

This is why I asked about Yocto. Have you tested Parsec+PKCS11 in Yocto?
meta-security CI pipelines are broken, but they passed a copule weeks ago.
Maybe you can check how SoftHSM is built in Yocto

[gowthamsk-arm]

@anta5010 I ran the automated PKCS11 tests on yocto and its passing. The failure on the CI is due to the libts library using new RPC calls

[gowthamsk-arm]

the current release of the parsec should fix the ci failure

[anta5010]

@anta5010 I ran the automated PKCS11 tests on yocto and its passing. The failure on the CI is due to the libts library using new RPC calls

so, either Yocto toolchain or SoftHSM build parameters fix the pkcs11 issue you see in Parsec CI. If the latter then we can use the same approach in CI. Did you have a chance to have a look at SoftHSM Yocto recipe/version?

[gowthamsk-arm]

The yocto tests just run the cli tests as seen here
The failing test is part of e2e_tests in normal_tests, so its not running in the yocto.