Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
tgonzalezorlandoarm opened this issue May 8, 2024 · 16 comments
Labels
bug Something isn't working testing Task related to testing

Comments

@tgonzalezorlandoarm
Copy link
Member

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 tgonzalezorlandoarm added bug Something isn't working testing Task related to testing labels May 8, 2024
@tgonzalezorlandoarm
Copy link
Member Author

@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
Copy link
Member

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
Copy link
Collaborator

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
Copy link
Member Author

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

@tgonzalezorlandoarm
Copy link
Member Author

@anta5010 latest version of SoftHSM fails as well

@tgonzalezorlandoarm
Copy link
Member Author

@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
Copy link
Member Author

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
Copy link
Collaborator

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
Copy link
Contributor

@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
Copy link
Contributor

the current release of the parsec should fix the ci failure

@anta5010
Copy link
Collaborator

@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
Copy link
Contributor

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.

@gowthamsk-arm
Copy link
Contributor

Projects which include Parsec via meta-security, like Cassini, are currently seeing build failures due to the trusted service v1.0.0 update on meta-arm. Can we merge #764 for publishing the new parsec version to fix the TS issue and continue the discussion on this ticket in the meantime?

@anta5010
Copy link
Collaborator

I don't see any problem with that as long as we have this issue open :)

@anta5010
Copy link
Collaborator

Projects which include Parsec via meta-security, like Cassini, are currently seeing build failures due to the trusted service v1.0.0 update on meta-arm.

Most likely they use scarthgap Yocto release. Please remember to update Parsec recipes in scarthgap as well as in master. We used to time Parsec releases before Yocto release. But, not this time.

@gowthamsk-arm
Copy link
Contributor

Yes I will send the patches to both master and scarthgap :)

gowthamsk-arm pushed a commit that referenced this issue May 14, 2024
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 is due to an issue in SoftHSMv2.

See #761 for
more information.

Signed-off-by: Tomás González <[email protected]>
@github-project-automation github-project-automation bot moved this to All issues in Parsec Aug 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working testing Task related to testing
Projects
Status: All issues
Development

No branches or pull requests

4 participants